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

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 >> Subject: Re: questions about draft-wen-ipv6-rsra-opt-multihoming-00 >> >> >> >> >> I'd like to point out that the multi6 WG has completed it's work and >> should be closed down - and as soon as that happens I will >> close this >> mailinglist. >> >> - kurtis - >> >> On 6 jun 2006, at 06.04, Lawrence Zou wrote: >> >> > 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? >> > >> > >> > >> > >> >> >
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:
1)ISP1 and ISP2 send RA with prefix information and multi-homing
information.
2)if host can decide whitch ISP it will select,for example ,it select
ISP1,the host will form address with
 the prefix in the RA of ISP1 and ignore  the RA of ISP2.

>
>Host knows which ISP it will got its service, and it also 
>knows its exit router is the edge router of the desired ISP. 
>But it doesn't know the network topology, it doesn't know the 
>exact exit router either, unless multi-homing informaiton 
>option is used along the prefix information option.

i do not agree with this point of "Host knows which ISP it will got its
service" in the scenario 
of  stateless address auto-configure,in the SAAC,we should assume that
No manual configuration 
of individual machines  before connecting them to the network, but if
you do not do some manual configuration,
how can you know which ISP the host will got its service?One available
method the host can do this is it ask "who
can provide the service of......?" and if someone  anwer it "i can do it
",then the host select this ISP.
>
>Best regards,
>
>Haibo
>
>
>> -----Original Message-----
>> From: Lawrence Zou [mailto:zou.rong <at> huawei.com]
>> Sent: 2006年6月6日 15:09
>> To: CTO WEN Haibo
>> Cc: multi6 <at> ops.ietf.org; shim6 <at> psg.com
>> Subject: 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-----
>> >From: CTO WEN Haibo [mailto:Haibo.WEN <at> alcatel-sbell.com.cn]
>> >Sent: Tuesday, June 06, 2006 1:44 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
>> >
>> >
>> >hi Lawrence,
>> >
>> >I'm glad to receive your comments.
>> >
>> >I can explain to you one by one.
>> >
>> >1. The secnarios in the draft are using the ISP name
>> >sub-option. It does not 
>> >mean that it's a "MUST" sub-option in the multi-homing 
>> >information option for 
>> >RS message (and other sub-option can be used if needed). Of 
>> >course, if we want to solve the problem described in the 
>> >charter of shim6 w.g., it is a "MUST" sub-option for RA 
>> >message. Without this information along with the Prefix 
>> >Information option, host doesn't know how to choose the 
>> >appropriate prefix and 
>> >the associated exit router. 
>> >I think multi-homing environment doesn't mean that some hosts 
>> >in a multi- home site just in the VLAN connected to a 
>> >specified ISP. All the hosts in the 
>> >multihome site have been connected to all the exit routers 
>> >that belongs to 
>> >different ISP. That is, the host can obtain all the periodical 
>> >RA messages from different routers. Our goal is to solve 
>> >prefix selection and exit router selection in this environment.
>> >
>> >2. First, that's just an example of how to use multi-homing
>> >option in access network. It can also be used in LAN with 
>> >multiple exit routers. The layer2 access node I mean in this 
>> >example is not just a pure layer2 devices. It can snoop some 
>> >special layer3 packets, such as RS/RA messages, then it can 
>> >forward the RS to the correct router without flooding it to 
>> >other parts of 
>> >access netework. 
>> >If the access node doesn't have this ability, RS can be sent 
>> >to all routers, only the corresponding will respond this RS 
>> >message. This will not add any bad 
>> >impact.
>> >
>> >Thanks.
>> >
>> >Best regards,
>> >
>> >Haibo
>> >
>> >
>> >
>> >> -----Original Message-----
>> >> From: Lawrence Zou [mailto:zou.rong <at> huawei.com]
>> >> Sent: 2006年6月6日 12:04
>> >> To: CTO WEN Haibo
>> >> Cc: multi6 <at> ops.ietf.org
>> >> Subject: 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?	
>> >>   
>> >> 
>> >> 
>> >> 
>> >
>> 
>> 
>> 
>

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----- >From: CTO WEN Haibo [mailto:Haibo.WEN <at> alcatel-sbell.com.cn] >Sent: Tuesday, June 06, 2006 1:44 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 > > >hi Lawrence, > >I'm glad to receive your comments. > >I can explain to you one by one. > >1. The secnarios in the draft are using the ISP name >sub-option. It does not >mean that it's a "MUST" sub-option in the multi-homing >information option for >RS message (and other sub-option can be used if needed). Of >course, if we want to solve the problem described in the >charter of shim6 w.g., it is a "MUST" sub-option for RA >message. Without this information along with the Prefix >Information option, host doesn't know how to choose the >appropriate prefix and >the associated exit router. >I think multi-homing environment doesn't mean that some hosts >in a multi- home site just in the VLAN connected to a >specified ISP. All the hosts in the >multihome site have been connected to all the exit routers >that belongs to >different ISP. That is, the host can obtain all the periodical >RA messages from different routers. Our goal is to solve >prefix selection and exit router selection in this environment. > >2. First, that's just an example of how to use multi-homing >option in access network. It can also be used in LAN with >multiple exit routers. The layer2 access node I mean in this >example is not just a pure layer2 devices. It can snoop some >special layer3 packets, such as RS/RA messages, then it can >forward the RS to the correct router without flooding it to >other parts of >access netework. >If the access node doesn't have this ability, RS can be sent >to all routers, only the corresponding will respond this RS >message. This will not add any bad >impact. > >Thanks. > >Best regards, > >Haibo > > > >> -----Original Message----- >> From: Lawrence Zou [mailto:zou.rong <at> huawei.com] >> Sent: 2006年6月6日 12:04 >> To: CTO WEN Haibo >> Cc: multi6 <at> ops.ietf.org >> Subject: 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? >> >> >> >> >
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?	

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
---

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
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.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST <at> IETF.ORG.  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST <at> RFC-EDITOR.ORG.

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info <at> RFC-EDITOR.ORG with the message body 
help: ways_to_get_rfcs.  For example:

        To: rfc-info <at> RFC-EDITOR.ORG
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to RFC-Manager <at> RFC-EDITOR.ORG.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
RFC-EDITOR <at> RFC-EDITOR.ORG.  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.
Attachment: message/external-body, 102 bytes
Attachment (rfc4218.txt): message/external-body, 72 bytes
_______________________________________________
IETF-Announce mailing list
IETF-Announce <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ietf-announce
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.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST <at> IETF.ORG.  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST <at> RFC-EDITOR.ORG.

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info <at> RFC-EDITOR.ORG with the message body 
help: ways_to_get_rfcs.  For example:

        To: rfc-info <at> RFC-EDITOR.ORG
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to RFC-Manager <at> RFC-EDITOR.ORG.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
RFC-EDITOR <at> RFC-EDITOR.ORG.  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.
Attachment: message/external-body, 102 bytes
Attachment (rfc4219.txt): message/external-body, 72 bytes
_______________________________________________
IETF-Announce mailing list
IETF-Announce <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ietf-announce
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.

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

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST <at> IETF.ORG.  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST <at> RFC-EDITOR.ORG.

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info <at> RFC-EDITOR.ORG with the message body 
help: ways_to_get_rfcs.  For example:

        To: rfc-info <at> RFC-EDITOR.ORG
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to RFC-Manager <at> RFC-EDITOR.ORG.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
RFC-EDITOR <at> RFC-EDITOR.ORG.  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.
Attachment: message/external-body, 102 bytes
Attachment (rfc4177.txt): message/external-body, 72 bytes
_______________________________________________
IETF-Announce mailing list
IETF-Announce <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ietf-announce
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
not specify an Internet standard of any kind.  Distribution of this
memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST <at> IETF.ORG.  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST <at> RFC-EDITOR.ORG.

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info <at> RFC-EDITOR.ORG with the message body 
help: ways_to_get_rfcs.  For example:

        To: rfc-info <at> RFC-EDITOR.ORG
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to RFC-Manager <at> RFC-EDITOR.ORG.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
RFC-EDITOR <at> RFC-EDITOR.ORG.  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.
Attachment: message/external-body, 102 bytes
Attachment (rfc4116.txt): message/external-body, 72 bytes
_______________________________________________
IETF-Announce mailing list
IETF-Announce <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ietf-announce
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



Gmane