headers
IESG Secretary | 17 Mar 15:50
Picon
Favicon

WG Action: Conclusion of Site Multihoming in IPv6 WG (multi6)

The Site Multihoming in IPv6 WG (multi6) in the Operations and Management
Area has concluded.

The IESG contact persons are Davis Kessens and Dan Romascanu.

The mailing list will be closed.

_______________________________________________
IETF-Announce mailing list
IETF-Announce <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ietf-announce
Permalink | Reply | 0 comments |
headers
Lawrence Zou | 7 Jun 05:18
Favicon

RE: questions about draft-wen-ipv6-rsra-opt-multihoming-00

I am not sure the topic  in your document is in the domain of  shim6,in
fact ,I think it will be bettter to discuss in IPV6 WG because you want
to add option in RS/RA message.

>-----Original Message-----
>From: CTO WEN Haibo [mailto:Haibo.WEN <at> alcatel-sbell.com.cn] 
>Sent: Wednesday, June 07, 2006 9:34 AM
>To: Kurt Erik Lindqvist; Lawrence Zou
>Cc: multi6 <at> ops.ietf.org
>Subject: RE: questions about draft-wen-ipv6-rsra-opt-multihoming-00
>
>
>Kurtis,
>
>Thank you for your reminder.
>I have subscribed the shim6 WG, and also forwarded the 
>discussion in that group.
>
>Lawrence, maybe you should subscribe shim6 WG, too.
>
>Best regards,
>
>-Haibo
>
>
>> -----Original Message-----
>> From: Kurt Erik Lindqvist [mailto:kurtis <at> kurtis.pp.se]
>> Sent: 2006年6月7日 08:50
>> To: Lawrence Zou
>> Cc: CTO WEN Haibo; multi6 <at> ops.ietf.org
(Continue reading)

Permalink | Reply | 0 comments |
headers
Lawrence Zou | 6 Jun 11:32
Favicon

RE: questions about draft-wen-ipv6-rsra-opt-multihoming-00


>-----Original Message-----
>From: CTO WEN Haibo [mailto:Haibo.WEN <at> alcatel-sbell.com.cn] 
>Sent: Tuesday, June 06, 2006 4:54 PM
>To: Lawrence Zou
>Cc: multi6 <at> ops.ietf.org; shim6 <at> psg.com
>Subject: RE: questions about draft-wen-ipv6-rsra-opt-multihoming-00
>
>
>Lawrence,
>
>In current IPv6 multihoming site, each hosts in this site can 
>have multiple prefixes from different exit routers. It cannot 
>identify which ISP assignes 
>the exact prefix, because there is no extra information in 
>prefix information option.
>
>The multi-homing information defined in this draft is used 
>along with prefix information option. It will provide extra 
>information for host to do selection. Host only selects the 
>prefix from the desired ISP to form its IPv6 address, of 
>course, the corresponding exit router will be cached. Other 
>prefixes from other routers will not be used to form IP 
>address. For example, STB may only want services from IPTV 
>service provider. Other prefixes from other service providers 
>are useless for itself.

yes,i think you point out the most important thing:the host only form IP
adress it will use it .
so i guess that:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Lawrence Zou | 6 Jun 09:08
Favicon

RE: questions about draft-wen-ipv6-rsra-opt-multihoming-00

sorry,I am confused by your draft.

in section 1 you mentioned the purpose of your idear is  "How to help
host implement 
   exit router selection and the associated prefix or address selection
"

in my understand ,
your prblem is the host have got several prefix or addresses from
different routers,when the host have some data to send to a destination,
it must choose a source address and a exit router. is that true?

for this purpose ,the host send RS with the multihome-option that carry
some information such as ISP name ,then  the corresponding exit router
response it  wiht  RA.

but  I think if the host have know which ISP it will got it's
service(explicit by ISP name),that also mean the host have already
selected one exit router and the corresponding source address.

maybe i have misunderstand the procedure.can you explain it more
explicit ? 

thanks 

Best regards

Lawrence

>-----Original Message-----
(Continue reading)

Permalink | Reply | 0 comments |
headers
Lawrence Zou | 6 Jun 06:04
Favicon

questions about draft-wen-ipv6-rsra-opt-multihoming-00

hi,wen:

     i have read you draft.  Although there are some strong technical
points in this document,  i still think there are some big problem:

1. I noticed  that in all 3 Scenarios, the RS message must include ISP
name sub-option,so,is it a "MUST"  sub-optinon that be include in the 
Multi-homing Information option? if it is true,what will it happen if
the host don't know the name of the ISP? I think in the Scenarios of
stateless 
addres autoconfigue, it is not necessary for host to know the topology
of the network and the name of the ISP.
in your draft ,all hosts know clearly which ISP they belong to ,I think
we can distinguish them using some kinds of  VLAN techonoly.

2.In Scenario 3,you mention the equipment of "layer2 CPE ".so what the
difference is that with "layer3 CPE "? In my understand ,the layer2 CPE 
is a layer2 equipmnet ,so in the section 3.3 
   Step (b) : Base on the information in Multi-homing Information option
              , layer 2 access node can forward this RS to the correct
              edge router of the desired ISP without sending it to the 
              router that will not respond this RS.	

 can layer2 equipment do this kind of thing?
Permalink | Reply | 1 comment |
headers
David Kessens | 18 Nov 03:38
Picon

Closing of the multi6 working group


Hi,

After consulation with the working group chairperson, I would like to
close the multi6 working group as all milestones are now completed. 

In addition, I don't see much reason to keep the mail list since an
active mail list (shim6 mail list) is available.

Please let me know if you don't agree by the end of the day, Nov 30,
2005 (pick your favorite timezone ;-)).

Finally, I would like to thank the working group for successfully
completing all the milestones! I sincerely hope that the shim6 effort
that is now well underway will result in a workable solution for many
sites that are interested in multi-homing their networks.

David Kessens
---
Permalink | Reply | 0 comments |
headers
rfc-editor | 1 Nov 01:50
Favicon

RFC 4218 on Threats Relating to IPv6 Multihoming Solutions


A new Request for Comments is now available in online RFC libraries.

        RFC 4218

        Title:      Threats Relating to IPv6 Multihoming Solutions
        Author(s):  E. Nordmark, T. Li
        Status:     Informational
        Date:       October 2005
        Mailbox:    erik.nordmark <at> sun.com, Tony.Li <at> tony.li
        Pages:      31
        Characters: 75969
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-multi6-multihoming-threats-03.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc4218.txt

This document lists security threats related to IPv6 multihoming.
Multihoming can introduce new opportunities to redirect packets to
different, unintended IP addresses.

The intent is to look at how IPv6 multihoming solutions might make
the Internet less secure; we examine threats that are inherent to
all IPv6 multihoming solutions rather than study any specific
proposed solution.  The threats in this document build
upon the threats discovered and discussed as part of the Mobile IPv6
work. 

This document is a product of the Site Multihoming in IPv6 Working
(Continue reading)

Permalink | Reply | 0 comments |
headers
rfc-editor | 1 Nov 01:52
Favicon

RFC 4219 on Things Multihoming in IPv6 (MULTI6) Developers Should Think About


A new Request for Comments is now available in online RFC libraries.

        RFC 4219

        Title:      Things Multihoming in IPv6 (MULTI6) Developers
                    Should Think About
        Author(s):  E. Lear
        Status:     Informational
        Date:       October 2005
        Mailbox:    lear <at> cisco.com
        Pages:      12
        Characters: 25141
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-multi6-things-to-think-about-01.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc4219.txt

This document specifies a set of questions that authors should be
prepared to answer as part of a solution to multihoming with IPv6.
The questions do not assume that multihoming is the only problem of
interest, nor do they demand a more general solution.

This document is a product of the Site Multihoming in IPv6 Working
Group of the IETF.

This memo provides information for the Internet community.  It does
not specify an Internet standard of any kind.  Distribution of this
memo is unlimited.
(Continue reading)

Permalink | Reply | 0 comments |
headers
rfc-editor | 1 Oct 01:28
Favicon

RFC 4177 on Architectural Approaches to Multi-homing for IPv6


A new Request for Comments is now available in online RFC libraries.

        RFC 4177

        Title:      Architectural Approaches to Multi-homing for IPv6
        Author(s):  G. Huston
        Status:     Informational
        Date:       September 2005
        Mailbox:    gih <at> apnic.net
        Pages:      36
        Characters: 95374
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-multi6-architecture-04.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc4177.txt

This memo provides an analysis of the architectural aspects of
multi-homing support for the IPv6 protocol suite.  The purpose of
this analysis is to provide a taxonomy for classification of various
proposed approaches to multi-homing.  It is also an objective of
this exercise to identify common aspects of this domain of study, and
also to provide a framework that can allow exploration of some of the
further implications of various architectural extensions that are
intended to support multi-homing.

This document is a product of the Site Multihoming in IPv6 Working
Group of the IETF.
(Continue reading)

Permalink | Reply | 0 comments |
headers
rfc-editor | 23 Jul 00:07
Favicon

RFC 4116 on IPv4 Multihoming Practices and Limitations


A new Request for Comments is now available in online RFC libraries.

        RFC 4116

        Title:      IPv4 Multihoming Practices and Limitations
        Author(s):  J. Abley, K. Lindqvist, E. Davies, B. Black,
                    V. Gill
        Status:     Informational
        Date:       July 2005
        Mailbox:    jabley <at> isc.org, kurtis <at> kurtis.pp.se,
                    elwynd <at> dial.pipex.com, ben <at> layer8.net,
                    vgill <at> vijaygill.com
        Pages:      13
        Characters: 26598
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-multi6-v4-multihoming-03.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc4116.txt

Multihoming is an essential component of service for many Internet
sites.  This document describes some implementation strategies for
multihoming with IPv4 and enumerates features for comparison with
other multihoming proposals (particularly those related to IPv6).

This document is a product of the Site Multihoming in IPv6 Working
Group of the IETF.

This memo provides information for the Internet community.  It does
(Continue reading)

Permalink | Reply | 0 comments |
headers
Smd | 18 Jul 11:13

Re:

+----------------------------------------------------+

Panda GateDefender has detected malicious content (Virus) in the following file: [Dog.cpl]
W32/Bagle.AH.worm

The file has been deleted to protect the network.
07/18/2005 08:07 +0100

www.pandasoftware.com

+----------------------------------------------------+

>Predators


Permalink | Reply | 6 comments |

Gmane