From owner-ipng@sunroof.eng.sun.com Wed Oct 4 08:12:58 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) id e94FBTk24236 for ipng-dist; Wed, 4 Oct 2000 08:11:29 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e94FBI324225 for ; Wed, 4 Oct 2000 08:11:19 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA03104 for ; Wed, 4 Oct 2000 08:11:19 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA09012 for ; Wed, 4 Oct 2000 08:11:17 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id IAA12165; Wed, 4 Oct 2000 08:11:17 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id e94FBFs03270; Wed, 4 Oct 2000 08:11:15 -0700 X-Virus-Scanned: Wed, 4 Oct 2000 08:11:15 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdgZJFzw; Wed, 04 Oct 2000 08:11:11 PDT Message-ID: <39DB4891.4D00FE56@iprg.nokia.com> Date: Wed, 04 Oct 2000 08:11:13 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Francis Dupont CC: Mobile IP Mailing List , IPng Working Group Subject: Proposal for new Destination Options placement Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello Francis et al., I am writing this note in response to your note, appended after the main body of this note. I have been studying the issues relevant to the placement of the Home Address option and the Binding Update option, in preparation for making a new revision for Mobile IPv6. It is a tough problem. I agree with you that the existing choices for ordering AH and Destination Options are not sufficient. In my mind, the first and most serious error, that affects the placement of the Home Address option, is it has to go before AH, but there is no need at all for it to be processed by the intermediate routing points of a routing header. Therefore, I'd like to suggest that in the Mobile IPv6 specification, we enable the placement of Destination Options after the Routing Header, but before the Fragment Header. This will enable the correct placement of the Home Address destination option, and it will greatly simplify any needed firewall treatment. Regards, Charlie P. -------- Original Message -------- Subject: Re: [MOBILE-IP] Implementation Issues re MobileIP and IPSec Date: Tue, 1 Aug 2000 21:16:56 +0200 From: Francis Dupont Reply-To: Francis.Dupont@ENST-BRETAGNE.FR To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM In your previous mail you wrote: > => this point was signaled by me and others... The final document > is supposed to fix it. So, the care-of-address is used as the IP source address for the authentication calculations. Correct? => we need both the home and the care-of address, one will be in the source address field, the other in the home address option. But we have to wait for the final document to know the exact order (ie. swapped (me) or not (Microsoft)). > => I disagree because you put more in "Binding Update option processing" > than it should be. In fact when you decode the BU you don't know if there > is an AH after or (the argument :-) a HA option. Now, I am confused ... Since we propose to put the BU in the 2nd Destination Options header, this problem wouldn't occur. => you can put the BU in the first/only DO header before the HA: you have replaced "MUST include" by "MUST be before" which is far stronger... (*) The only constraint in the order is there MUST be a DO header with a HA option before the AH header, you can put the BU where you'd like (before or after, in the same header than the HA or in an other one. In my code I put it in the same header than the HA in the order which gives the smallest length). By the time we get to the BU message, we have already processed the HA option (which MUST be in the 1st Destination Options header) and the AH (which MUST occur before the 2nd Destination Options header). => the second MUST is yours and obviously is incorrect because I can implement this with only one DO header... > I execute the BU only > when I see the upper layer header, the processing itself is restricted > to length/alignement checks. So, what would you say are the advantages of putting the BU in the 1st Destination Options header? => simpler, smaller, ... Or is it just convenience since only one of the Destination Options headers must be processed then? => of course it is convenience. But if you have an ESP header too our firewall implementors want to have all DO headers in clear, ie before the ESP. Then they convince me to keep the way I built the DO header before IPsec introduction and just add some code which: - puts the AH after the DO header - supports DO headers (and DO themselves) in *any* order on input Could anybody working on the "final document" respond to this question? => I'll try to catch Dave Johnson who is here (IETF, mobileip 1st session). > 2. It should clarify which address, the mobile node's Home Address or > care-of-address, must be used for the SA/SP lookup. > > => this is clearly specified in the I-D (home address must be used). Could you please point out the respective section? => section 10.2 (inbound processing must be symmetrical). Beware that IKE rules are a bit hairy (but less than IKE itself :-). Regards Francis.Dupont@enst-bretagne.fr, PS *: to put the HA option after the BU option is a favorite in the UNH mobile IPv6 test suite... -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 4 09:47:01 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) id e94GjRi24403 for ipng-dist; Wed, 4 Oct 2000 09:45:27 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e94GjN324396 for ; Wed, 4 Oct 2000 09:45:23 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id e94Gj4908371 for ipng@sunroof.eng.sun.com; Wed, 4 Oct 2000 09:45:04 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e94DbU324172 for ; Wed, 4 Oct 2000 06:37:31 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA04735 for ; Wed, 4 Oct 2000 06:37:31 -0700 (PDT) Received: from mailweb8.rediffmail.com ([202.54.124.153]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id HAA22708 for ; Wed, 4 Oct 2000 07:37:30 -0600 (MDT) Received: (qmail 28100 invoked by uid 510); 4 Oct 2000 13:28:08 -0000 Date: 4 Oct 2000 13:28:08 -0000 Message-ID: <20001004132808.28099.qmail@mailweb8.rediffmail.com> MIME-Version: 1.0 To: "ipng@sunroof.eng.sun.com" From: "manivannan Muniandi" Content-ID: Content-type: text/plain Content-Description: Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, I have the following doubt in IPv6 addressing and forwarding. As IPv6 supports hierarchical routing, here also do we have 'longest match' concept? If so, Can I use the same PATERCIA Algrithm for routing table? Can I have two host on the same lan having different Prefixes? If so, how the forwarding works? Regards, Vannan _________________________________________________ Get Your Free Email At, http://www.rediffmail.com For fabulous shopping deals visit: http://www.rediff.co.in/shopping/index.html -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 4 12:26:49 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) id e94JPKW24773 for ipng-dist; Wed, 4 Oct 2000 12:25:20 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e94JP9324766 for ; Wed, 4 Oct 2000 12:25:09 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA12321 for ; Wed, 4 Oct 2000 12:25:08 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA15235 for ; Wed, 4 Oct 2000 12:25:08 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id MAA07165; Wed, 4 Oct 2000 12:25:08 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id e94JP5G11297; Wed, 4 Oct 2000 12:25:05 -0700 X-Virus-Scanned: Wed, 4 Oct 2000 12:25:05 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from spruce.iprg.nokia.com (205.226.1.63) by darkstar.iprg.nokia.com(WTS.12.69) smtpdGAjjM7; Wed, 04 Oct 2000 12:25:00 PDT Message-Id: <4.3.2.7.2.20001004122038.0269da00@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 04 Oct 2000 12:23:53 -0700 To: "manivannan Muniandi" From: Bob Hinden Subject: Re: Cc: "ipng@sunroof.eng.sun.com" In-Reply-To: <20001004132808.28099.qmail@mailweb8.rediffmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Manivannan, >As IPv6 supports hierarchical routing, here also do we have 'longest >match' concept? If so, Can I use the same PATERCIA Algrithm for routing table? Yes, IPv6 routing works just like IPv4. All type of longest match lookup algorithms are fine. >Can I have two host on the same lan having different Prefixes? If so, how >the forwarding works? Yes, the node would need to sent the packet to a router that knew about both prefixes. Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 5 05:17:24 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) id e95CFHb25496 for ipng-dist; Thu, 5 Oct 2000 05:15:17 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e95CF7325488 for ; Thu, 5 Oct 2000 05:15:08 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id FAA01311 for ; Thu, 5 Oct 2000 05:15:06 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA17361 for ; Thu, 5 Oct 2000 05:15:04 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e95CEWs53917; Thu, 5 Oct 2000 14:14:32 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id OAA29537; Thu, 5 Oct 2000 14:14:31 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id OAA98905; Thu, 5 Oct 2000 14:17:45 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200010051217.OAA98905@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Charles E. Perkins" cc: Francis Dupont , Mobile IP Mailing List , IPng Working Group Subject: Re: Proposal for new Destination Options placement In-reply-to: Your message of Wed, 04 Oct 2000 08:11:13 PDT. <39DB4891.4D00FE56@iprg.nokia.com> Date: Thu, 05 Oct 2000 14:17:45 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: I agree with you that the existing choices for ordering AH and Destination Options are not sufficient. In my mind, the first and most serious error, that affects the placement of the Home Address option, is it has to go before AH, but there is no need at all for it to be processed by the intermediate routing points of a routing header. Therefore, I'd like to suggest that in the Mobile IPv6 specification, we enable the placement of Destination Options after the Routing Header, but before the Fragment Header. This will enable the correct placement of the Home Address destination option, and it will greatly simplify any needed firewall treatment. => we agree. We'll get three kinds of destination options extension headers: - "note 1" which are not used (IMHO we should garbage collected them). - new DO headers between the routing header (if any) and the fragmentation header (if any). I believe the tunnel encapsulation limit should go there too (ie. with the home address option) because this will limit over-encapsulated fragments (and over-encapsulation would produce fragments). - "note 3" well known DO headers which will be used today only for binding options then should get a new value for its next-header type (this will not introduce major interoperability problems and will make things far simpler to understand ans to implement). Thanks Francis.Dupont@enst-bretagne.fr PS: this mail is the result of a meeting at IPv6 bake-off organized by ETSI between all present mobile IPv6 gurus... -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 5 09:33:35 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) id e95GVVN25685 for ipng-dist; Thu, 5 Oct 2000 09:31:31 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e95GVH325674 for ; Thu, 5 Oct 2000 09:31:19 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA15358; Thu, 5 Oct 2000 09:31:17 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA23332; Thu, 5 Oct 2000 09:31:16 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA25165; Thu, 5 Oct 2000 09:30:44 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id e95GUgJ16487; Thu, 5 Oct 2000 09:30:42 -0700 X-Virus-Scanned: Thu, 5 Oct 2000 09:30:42 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from spruce.iprg.nokia.com (205.226.1.63) by darkstar.iprg.nokia.com(WTS.12.69) smtpdKwh38h; Thu, 05 Oct 2000 09:20:45 PDT Message-Id: <4.3.2.7.2.20001004144606.01d2ae20@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 05 Oct 2000 09:19:00 -0700 To: Thomas Narten , Erik.Nordmark@eng.sun.com From: Bob Hinden Subject: Revised IPng Working Group Charter Cc: ipng@sunroof.eng.sun.com, scoya@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas, Erik, Attached is the revised charter for the IPng working group. Updating the charter was agreed to at the Grenoble and Minneapolis working group meetings. This version has been discussed on the ipng mailing list and at the Adelaide IETF meeting. The charter includes changing the name of the working group to the "IP Version 6 Working Group", but will keep the acronym of "ipngwg". This will avoid having to rename all current internet drafts. Bob Hinden / Steve Deering ----------------------------------------------------------------------------- IP Version 6 Working Group (ipngwg) *** note: change of name but not acronym Chair(s): Bob Hinden Steve Deering Document Editor Bob Hinden (hinden@iprg.nokia.com) Internet Area Director(s): Thomas Narten Erik Nordmark Internet Area Advisor: Thomas Narten Mailing Lists: General Discussion:ipng@sunroof.eng.sun.com To Subscribe: majordomo@sunroof.eng.sun.com In Body: in body: subscribe ipng Archive: ftp://playground.sun.com/pub/ipng/mail-archive Description of Working Group: IP version 6 or IPv6 (also formerly known as IP Next Generation or IPng) is intended to support the continued growth of the Internet, both in size and capabilities, by offering a greatly increased IP address space and other enhancements over IPv4. The working group was originally chartered to implement the recommendations of the IPng Area Directors as outlined at the July 1994 IETF meeting and in "The Recommendation for the IP Next Generation Protocol," RFC1752, January 1995. Most of the tasks in that original charter have been completed, and the core IPv6 protocol specifications are now on the IETF standards track. The working group's ongoing responsibilities are as follows: - Complete work from the original charter and follow-on work, as outlined below. - Keep all IPv6 working group documents moving along publication / standardization track. - Serve as a review board and body of competence and coordination for IPv6 architectural issues that span multiple IETF working groups. - Provide a home for IPv6-related work that doesn't fit in an existing IETF working group and doesn't merit a working group of its own. - Provide technical input to ICANN, Internet Address Registries, and IANA with regard to IPv6 address allocation policies and procedures. - Provide technical input and review to IANA with regard to IPv6 protocol and parameter assignments. The list of the working group's current work items is as follows: - Revise ICMPv6 spec (scope-exceeded err, no error to redirect, editorial) - Revise Generic Tunneling spec (add bidirectional tunnels) - Update Basic and Advanced API specs - Complete Scoped Address Architecture spec and any necessary revisions to other working group drafts required to properly implement support for IPv6 address scoping - Complete work on recommended address-selection algorithms - Work on new solutions to site-multihoming problems, possibly including both host-based and router-based solutions. - Complete work on local IPv6 networking as part of IPv6 plug-and-play - Complete work on privacy extensions to stateless address configuration - Document IPv6 renumbering model - Complete the GSE Analysis document - Complete the Inverse Neighbor Discovery spec - Complete the IPv6 Node Information Queries spec - Complete MIB specs as required by any working group protocol specs New work items not listed above require the approval of the working group and Internet Area directors before they will be taken on by the working group. The working group would welcome contributions on the following topics (this is not an exhaustive list): - Flow label standardization - Solutions to other multihoming issues, beyond those specific to site-multihoming - Integration of autoconfiguration, mobility, DNS, service discovery and other technologies to enhance IPv6 plug-and-play - IPv6 dial-up issues relating to address assignment, use of Neighbor Discovery, etc. (not including AAA work) - Specifications for IPv6 over additional media - Extending MLD to include functionality of IGMPv3 - Host use of anycast; TCP use of anycast - Support for multi-link subnets (single subnet spans multiple links) - Scope-name discovery - IPv6 protocol extensions to accommodate mobile wireless networks. Goals and Milestones: Aug 2000 Complete MLD MIB and submit for Proposed Standard Sep 2000 Complete privacy extensions specification and submit for Proposed Standard Nov 2000 Completed revision of GSE Analysis document and resubmit for Informational Sep 2000 Complete the Inverse Neighbor Discovery specification and submit for Proposed Standard Sep 2000 Complete IPv6 Multihoming with Route Aggregation and submit for Informational. Dec 2000 Update ICMP document and resubmit for Draft Standard Dec 2000 Update Generic Tunneling specification and resubmit for Proposed Standard Nov 2000 Complete updates to Basic and Advanced API specifications and submit for Informational Dec 2000 Complete Scoped Address Architecture and submit for Proposed Standard Dec 2000 Compete Address Selection specification and submit for Proposed Standard Dec 2000 Complete Local IPv6 Networking Specification and submit for Proposed Standard Dec 2000 Complete the IPv6 Node Information Queries specification and submit for Proposed Standard Mar 2001 Complete IPv6 renumbering model document and submit for Informational ----------------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Oct 5 10:32:23 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) id e95HUe325819 for ipng-dist; Thu, 5 Oct 2000 10:30:40 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.86.31] (may be forged)) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e95HUT325812 for ; Thu, 5 Oct 2000 10:30:29 -0700 (PDT) Received: from lillen (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.11.1+Sun/8.11.1) with SMTP id e95HUMh564090; Thu, 5 Oct 2000 10:30:22 -0700 (PDT) Date: Thu, 5 Oct 2000 10:29:59 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Revised IPng Working Group Charter To: Bob Hinden Cc: Thomas Narten , Erik.Nordmark@eng.sun.com, ipng@sunroof.eng.sun.com, scoya@ietf.org In-Reply-To: "Your message with ID" <4.3.2.7.2.20001004144606.01d2ae20@mailhost.iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > - IPv6 protocol extensions to accommodate mobile wireless networks. Bob, I think IPv6 already accomodates these networks. Shouldn't the charter say "further accomodate" or something like it? Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Oct 6 02:41:01 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) id e969dMG26577 for ipng-dist; Fri, 6 Oct 2000 02:39:22 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e969dD326570 for ; Fri, 6 Oct 2000 02:39:13 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id CAA09897 for ; Fri, 6 Oct 2000 02:39:12 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA15905 for ; Fri, 6 Oct 2000 03:39:08 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e969cvs40010; Fri, 6 Oct 2000 11:38:57 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id LAA16610; Fri, 6 Oct 2000 11:38:56 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id LAA03274; Fri, 6 Oct 2000 11:42:15 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200010060942.LAA03274@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Bob Hinden cc: ipng@sunroof.eng.sun.com Subject: Re: Revised IPng Working Group Charter In-reply-to: Your message of Thu, 05 Oct 2000 09:19:00 PDT. <4.3.2.7.2.20001004144606.01d2ae20@mailhost.iprg.nokia.com> Date: Fri, 06 Oct 2000 11:42:15 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: The working group would welcome contributions on the following topics (this is not an exhaustive list): - Extending MLD to include functionality of IGMPv3 => is there a written document for IPv6 somewhere? I'd like to add MLD a la IGMPv3 in BSD kernels, I believe the whole IPv4 stuff can be ported to IPv6 but perhaps (:-) I am not alone on this topics... Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Oct 6 03:33:49 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) id e96AV3226629 for ipng-dist; Fri, 6 Oct 2000 03:31:03 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e96AUZ326622 for ; Fri, 6 Oct 2000 03:30:35 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id DAA15474 for ; Fri, 6 Oct 2000 03:30:34 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA10960 for ; Fri, 6 Oct 2000 03:30:33 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27383; Fri, 6 Oct 2000 06:30:32 -0400 (EDT) Message-Id: <200010061030.GAA27383@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipngwg-addr-arch-v3-02.txt Date: Fri, 06 Oct 2000 06:30:32 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : IP Version 6 Addressing Architecture Author(s) : B. Hinden, S. Deering Filename : draft-ietf-ipngwg-addr-arch-v3-02.txt Pages : 25 Date : 05-Oct-00 This specification defines the addressing architecture of the IP Version 6 protocol [IPV6]. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-addr-arch-v3-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-addr-arch-v3-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-addr-arch-v3-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001005145816.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-addr-arch-v3-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-addr-arch-v3-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001005145816.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Oct 6 04:34:13 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) id e96BWaT26704 for ipng-dist; Fri, 6 Oct 2000 04:32:36 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e96BWR326697 for ; Fri, 6 Oct 2000 04:32:27 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id EAA29879 for ; Fri, 6 Oct 2000 04:32:26 -0700 (PDT) Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA23499 for ; Fri, 6 Oct 2000 04:32:26 -0700 (PDT) Received: from zbl6c016.corpeast.baynetworks.com (actually zbl6c016) by smtprch1.nortel.com; Fri, 6 Oct 2000 06:32:21 -0500 Received: from zbl6c000.corpeast.baynetworks.com ([132.245.205.50]) by zbl6c016.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id 4K2ZQMJP; Fri, 6 Oct 2000 07:32:13 -0400 Received: from nortelnetworks.com (clemson.corpeast.baynetworks.com [132.245.252.101]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id TFXDHPTF; Fri, 6 Oct 2000 07:32:11 -0400 Message-ID: <39DDB6C8.4044A265@nortelnetworks.com> Date: Fri, 06 Oct 2000 07:26:00 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Brian Haberman" Reply-To: "Brian Haberman" Organization: Nortel Networks X-Mailer: Mozilla 4.75 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Francis Dupont CC: Bob Hinden , ipng@sunroof.eng.sun.com Subject: Re: Revised IPng Working Group Charter References: <200010060942.LAA03274@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Francis, Not yet. Steve Deering and I have discussed it in the past and we have put it off until the IGMPv3 doc stabilized. I am planning on starting that task soon. Regards, Brian Francis Dupont wrote: > > In your previous mail you wrote: > > The working group would welcome contributions on the following topics > (this is not an exhaustive list): > > - Extending MLD to include functionality of IGMPv3 > > => is there a written document for IPv6 somewhere? I'd like to add > MLD a la IGMPv3 in BSD kernels, I believe the whole IPv4 stuff can be > ported to IPv6 but perhaps (:-) I am not alone on this topics... > > Regards > > Francis.Dupont@enst-bretagne.fr > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Oct 6 14:02:06 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) id e96KxYY27245 for ipng-dist; Fri, 6 Oct 2000 13:59:34 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e96KxM327238 for ; Fri, 6 Oct 2000 13:59:22 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA06249; Fri, 6 Oct 2000 13:59:21 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA26452; Fri, 6 Oct 2000 13:59:20 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA28721; Fri, 6 Oct 2000 13:59:19 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id e96KxFf15465; Fri, 6 Oct 2000 13:59:15 -0700 X-Virus-Scanned: Fri, 6 Oct 2000 13:59:15 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from spruce.iprg.nokia.com (205.226.1.63) by darkstar.iprg.nokia.com(WTS.12.69) smtpdZTCxur; Fri, 06 Oct 2000 13:59:11 PDT Message-Id: <4.3.2.7.2.20001006135159.02426b38@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 06 Oct 2000 13:57:48 -0700 To: Erik.Nordmark@eng.sun.com, narten@raleigh.ibm.com From: Bob Hinden Subject: Request to Advance "IP Version 6 Addressing Architecture" Cc: scoya@ietf.org, deering@cisco.com, ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, Thomas, The chairs of the IP Next Generation working group, on behalf of the working group, request that the following document be published as an Draft Standard: Title : IP Version 6 Addressing Architecture Author(s) : B. Hinden, S. Deering Filename : draft-ietf-ipngwg-addr-arch-v3-02.txt Pages : 25 Date : 05-Oct-00 A working group last call for this document was completed on April 10, 2000 and the document was discussed at the Adelaide IETF meeting. The -02 version of the draft resolves issues raised during the working group last call and subsequent discussion. This document will obsolete RFC2373. Changes from RFC2373 are listed in Appendix B. Bob Hinden / Steve Deering IPng Working Group Co-Chairs -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 9 09:46:36 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) id e99Gj2n28673 for ipng-dist; Mon, 9 Oct 2000 09:45:02 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e99Giw328666 for ; Mon, 9 Oct 2000 09:44:58 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id e99GiYU11312 for ipng@sunroof.eng.sun.com; Mon, 9 Oct 2000 09:44:34 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e99BnD328457 for ; Mon, 9 Oct 2000 04:49:14 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id EAA14025 for ; Mon, 9 Oct 2000 04:49:12 -0700 (PDT) Received: from mail.kebne.se (mail.kebne.se [212.209.134.151]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA03541 for ; Mon, 9 Oct 2000 05:49:10 -0600 (MDT) Received: by mail.kebne.se with Internet Mail Service (5.5.2448.0) id ; Mon, 9 Oct 2000 13:49:07 +0200 Message-ID: <31A473DBB655D21180850008C71E251A0283619E@mail.kebne.se> From: Thomas Eklund To: Bob Hinden , Thomas Narten , Erik.Nordmark@eng.sun.com Cc: ipng@sunroof.eng.sun.com, scoya@ietf.org Subject: RE: Revised IPng Working Group Charter Date: Mon, 9 Oct 2000 13:48:58 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I would like to see a "IPv6 router requirements" on the charts. Other important stuff is to define a MIB for mobileIPv6. Rgz -- Thomas > -----Original Message----- > From: owner-ipng@sunroof.eng.sun.com > [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Bob Hinden > Sent: Thursday, October 05, 2000 6:19 PM > To: Thomas Narten; Erik.Nordmark@Eng.Sun.COM > Cc: ipng@sunroof.eng.sun.com; scoya@ietf.org > Subject: Revised IPng Working Group Charter > > > Thomas, Erik, > > Attached is the revised charter for the IPng working group. > Updating the > charter was agreed to at the Grenoble and Minneapolis working group > meetings. This version has been discussed on the ipng > mailing list and at > the Adelaide IETF meeting. > > The charter includes changing the name of the working group > to the "IP > Version 6 Working Group", but will keep the acronym of > "ipngwg". This will > avoid having to rename all current internet drafts. > > Bob Hinden / Steve Deering > > -------------------------------------------------------------- > --------------- > > IP Version 6 Working Group (ipngwg) *** note: change of name > but not acronym > > Chair(s): > > Bob Hinden > Steve Deering > > Document Editor > > Bob Hinden (hinden@iprg.nokia.com) > > Internet Area Director(s): > > Thomas Narten > Erik Nordmark > > Internet Area Advisor: > > Thomas Narten > > Mailing Lists: > > General Discussion:ipng@sunroof.eng.sun.com > To Subscribe: majordomo@sunroof.eng.sun.com > In Body: in body: subscribe ipng > Archive: ftp://playground.sun.com/pub/ipng/mail-archive > > Description of Working Group: > > IP version 6 or IPv6 (also formerly known as IP Next > Generation or IPng) > is intended to support the continued growth of the > Internet, both in > size and capabilities, by offering a greatly increased IP > address space > and other enhancements over IPv4. The working group was > originally > chartered to implement the recommendations of the IPng > Area Directors > as outlined at the July 1994 IETF meeting and in "The > Recommendation > for the IP Next Generation Protocol," RFC1752, January > 1995. Most of > the tasks in that original charter have been completed, > and the core > IPv6 protocol specifications are now on the IETF standards track. > The working group's ongoing responsibilities are as follows: > > - Complete work from the original charter and follow-on work, as > outlined below. > > - Keep all IPv6 working group documents moving along > publication / > standardization track. > > - Serve as a review board and body of competence and > coordination for > IPv6 architectural issues that span multiple IETF > working groups. > > - Provide a home for IPv6-related work that doesn't fit > in an existing > IETF working group and doesn't merit a working group > of its own. > > - Provide technical input to ICANN, Internet Address > Registries, and > IANA with regard to IPv6 address allocation policies > and procedures. > > - Provide technical input and review to IANA with regard to IPv6 > protocol and parameter assignments. > > The list of the working group's current work items is as follows: > > - Revise ICMPv6 spec (scope-exceeded err, no error to redirect, > editorial) > - Revise Generic Tunneling spec (add bidirectional tunnels) > - Update Basic and Advanced API specs > - Complete Scoped Address Architecture spec and any > necessary revisions > to other working group drafts required to properly > implement support > for IPv6 address scoping > - Complete work on recommended address-selection algorithms > - Work on new solutions to site-multihoming problems, > possibly including > both host-based and router-based solutions. > - Complete work on local IPv6 networking as part of IPv6 > plug-and-play > - Complete work on privacy extensions to stateless > address configuration > - Document IPv6 renumbering model > - Complete the GSE Analysis document > - Complete the Inverse Neighbor Discovery spec > - Complete the IPv6 Node Information Queries spec > - Complete MIB specs as required by any working group > protocol specs > > New work items not listed above require the approval of > the working > group and Internet Area directors before they will be > taken on by the > working group. > > The working group would welcome contributions on the > following topics > (this is not an exhaustive list): > > - Flow label standardization > - Solutions to other multihoming issues, beyond those specific to > site-multihoming > - Integration of autoconfiguration, mobility, DNS, > service discovery > and other technologies to enhance IPv6 plug-and-play > - IPv6 dial-up issues relating to address assignment, > use of Neighbor > Discovery, etc. (not including AAA work) > - Specifications for IPv6 over additional media > - Extending MLD to include functionality of IGMPv3 > - Host use of anycast; TCP use of anycast > - Support for multi-link subnets (single subnet spans > multiple links) > - Scope-name discovery > - IPv6 protocol extensions to accommodate mobile > wireless networks. > > Goals and Milestones: > > Aug 2000 Complete MLD MIB and submit for Proposed Standard > > Sep 2000 Complete privacy extensions specification and submit for > Proposed Standard > > Nov 2000 Completed revision of GSE Analysis document and resubmit > for Informational > > Sep 2000 Complete the Inverse Neighbor Discovery specification > and submit for Proposed Standard > > Sep 2000 Complete IPv6 Multihoming with Route > Aggregation and submit > for Informational. > > Dec 2000 Update ICMP document and resubmit for Draft Standard > > Dec 2000 Update Generic Tunneling specification and resubmit for > Proposed Standard > > Nov 2000 Complete updates to Basic and Advanced API > specifications > and submit for Informational > > Dec 2000 Complete Scoped Address Architecture and submit > for Proposed > Standard > > Dec 2000 Compete Address Selection specification and > submit for Proposed > Standard > > Dec 2000 Complete Local IPv6 Networking Specification > and submit for > Proposed Standard > > Dec 2000 Complete the IPv6 Node Information Queries specification > and submit for Proposed Standard > > Mar 2001 Complete IPv6 renumbering model document and submit for > Informational > > -------------------------------------------------------------- > --------------- > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 9 23:16:26 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) id e9A6ERV00788 for ipng-dist; Mon, 9 Oct 2000 23:14:27 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e9A6EA300781 for ; Mon, 9 Oct 2000 23:14:12 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id XAA19929; Mon, 9 Oct 2000 23:13:59 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA27655; Mon, 9 Oct 2000 23:13:59 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id XAA01525; Mon, 9 Oct 2000 23:13:28 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id e9A6DOA31024; Mon, 9 Oct 2000 23:13:24 -0700 X-Virus-Scanned: Mon, 9 Oct 2000 23:13:24 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from Ihinden-5.iprg.nokia.com (205.226.22.78, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com(WTS.12.69) smtpdfQTqjw; Mon, 09 Oct 2000 23:13:20 PDT Message-Id: <4.3.2.7.2.20001009231052.01e089b8@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 09 Oct 2000 23:12:08 -0700 To: Thomas Eklund From: Bob Hinden Subject: RE: Revised IPng Working Group Charter Cc: Bob Hinden , Thomas Narten , Erik.Nordmark@eng.sun.com, ipng@sunroof.eng.sun.com, scoya@ietf.org In-Reply-To: <31A473DBB655D21180850008C71E251A0283619E@mail.kebne.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas, >I would like to see a "IPv6 router requirements" on the charts. Thanks. >Other important stuff is to define a MIB for mobileIPv6. This should be done in the Mobile IP w.g. who is developing Mobile IPv6. Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 10 01:25:06 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) id e9A8Mpc00920 for ipng-dist; Tue, 10 Oct 2000 01:22:51 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e9A8Me300913 for ; Tue, 10 Oct 2000 01:22:41 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id BAA12983 for ; Tue, 10 Oct 2000 01:22:39 -0700 (PDT) Received: from hotmail.com (f303.law9.hotmail.com [64.4.8.178]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA13230 for ; Tue, 10 Oct 2000 01:22:39 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 10 Oct 2000 01:22:39 -0700 Received: from 130.237.29.18 by lw9fd.law9.hotmail.msn.com with HTTP; Tue, 10 Oct 2000 08:22:38 GMT X-Originating-IP: [130.237.29.18] From: "karwan sorani" To: ipng@sunroof.eng.sun.com Subject: QUESTION! (Urgent..) Date: Tue, 10 Oct 2000 10:22:38 CEST Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 10 Oct 2000 08:22:39.0037 (UTC) FILETIME=[408456D0:01C03293] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I would like to find out how addressing Architeure in IPV6 is, specifically routing and routability of FED\10 (site Local)and 4\3 ? (provider Based Global Unicast).I need to answer to this question which include in my study of NAT-PT. _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Oct 13 01:18:55 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) id e9D8H5H05447 for ipng-dist; Fri, 13 Oct 2000 01:17:05 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e9D8Go305440 for ; Fri, 13 Oct 2000 01:16:50 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id BAA23828 for ; Fri, 13 Oct 2000 01:16:50 -0700 (PDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA04050 for ; Fri, 13 Oct 2000 01:16:49 -0700 (PDT) Received: from esebh12nok.ntc.nokia.com (esebh12nok.ntc.nokia.com [131.228.10.109]) by mgw-x2.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id e9D8GlP26664 for ; Fri, 13 Oct 2000 11:16:47 +0300 (EET DST) Received: from loki.research.nokia.com ([172.21.33.76]) by esebh12nok.ntc.nokia.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.78) id 4ZYX58AJ; Fri, 13 Oct 2000 11:16:47 +0300 Received: from possu.research.nokia.com (possu.research.nokia.com [172.21.33.80]) by loki.research.nokia.com (8.9.3/8.9.3) with ESMTP id LAA02319 for ; Fri, 13 Oct 2000 11:16:46 +0300 (EETDST) Received: from hews0169nrc (hed040-232.research.nokia.com [172.21.40.232]) by possu.research.nokia.com (8.9.1/8.9.1) with SMTP id LAA18092 for ; Fri, 13 Oct 2000 11:16:45 +0300 (EET DST) From: "Markku Savela" To: Subject: Time Exceeded and unknown extension headers before the ICMP header Date: Fri, 13 Oct 2000 11:16:43 +0300 Message-ID: <000001c034ed$eca677c0$e82815ac@hews0169nrc.research.nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A router is supposed to send Time Exceeded ICMP when hoplimit goes to zero. However, it should not send this error, if the packet itself is an ICMP error, right? Now, in IPv6 I see a potential problem in implementing above. If there are unknown extension headers in front of the ICMP, as follows: IPv6 [ext. hdrs] ICMP6[Time Exceeded] ... If the router doesn't implement that particular extension header (for example AH, but also something totally new), how is it supposed to know that it should not generate a new ICMP Time Exceeded? (extension headers cannot be skipped without knowing them, as not all extension headers follow the same structure). -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Oct 13 02:14:40 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) id e9D9DJo05546 for ipng-dist; Fri, 13 Oct 2000 02:13:19 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e9D9DA305539 for ; Fri, 13 Oct 2000 02:13:10 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id CAA15369 for ; Fri, 13 Oct 2000 02:13:09 -0700 (PDT) Received: from mailweb1.rediffmail.com ([202.54.124.146]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id CAA20526 for ; Fri, 13 Oct 2000 02:13:07 -0700 (PDT) Received: (qmail 3651 invoked by uid 510); 13 Oct 2000 08:38:09 -0000 Date: 13 Oct 2000 08:38:09 -0000 Message-ID: <20001013083809.3650.qmail@mailweb1.rediffmail.com> MIME-Version: 1.0 To: users@ipv6.org, ipng@sunroof.eng.sun.com, msripv6-users@list.research.microsoft.com From: "Murali Krishna Ch" Content-ID: Content-type: text/plain Content-Description: Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi All, Where can I find the IPv6 Mobility related information? -mur. _________________________________________________ Get Your Free Email At, http://www.rediffmail.com For fabulous shopping deals visit: http://www.rediff.co.in/shopping/index.html -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Oct 13 06:44:12 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) id e9DDgc605698 for ipng-dist; Fri, 13 Oct 2000 06:42:38 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e9DDgT305691 for ; Fri, 13 Oct 2000 06:42:29 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA21796 for ; Fri, 13 Oct 2000 06:42:29 -0700 (PDT) Received: from ish7.ericsson.com.au ([203.61.155.111]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA29857 for ; Fri, 13 Oct 2000 07:42:27 -0600 (MDT) Received: from brsi02.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id XAA20232; Fri, 13 Oct 2000 23:39:18 +1000 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id AAA06624; Sat, 14 Oct 2000 00:41:37 +1100 (EST) Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2650.21) id <4XFQPXLS>; Sat, 14 Oct 2000 00:41:45 +1100 Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A50C613C6A@eaubrnt018.epa.ericsson.se> From: "Hesham Soliman (EPA)" To: "'SungJin Lee'" , MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Cc: ipng@sunroof.eng.sun.com Subject: RE: [MOBILE-IP] MIPv6 node location detection Date: Sat, 14 Oct 2000 00:41:45 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > What is the difference between two advertisement below ? > - Renumbered home link router advertisement > - Router advertisement in a foreign link > > My question is why the mobile node don't just add the new address > in MN's address list. How do the MN decide whether it start MIPv6 > process or autoconfiguration process for renumbered home link address. > What if the all home addresses in the list have expired before the MN > get FA's router advertisement, can the MN still use the expired address > record > in it's system ? > => I think you're certainly asking the right question but perhaps to the wrong mailing list :) If I understand you correctly, you're saying that while the MN is at Home, if a new advertisement is received with a new prefix, how does it know that this is not another foreign subnet. Well based on my rusty knowledge of ND and stateless address configuration, it doesnt know. But I don't think that this is strictly a MIP issue. While you're at home MIP does not do anything for you. So that's why I'll cc IPng on this to see if someone can give you a better answer, or maybe I missed something here. BTW FA's do not exist in MIPv6. > I also can't find RFC or draft which define exactly address list in a > MIPv6 MN. A IPv6 node have a address list and every prefix has lifetime. > Please give me some advice on it. > > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Oct 13 06:50:15 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) id e9DDnPE05724 for ipng-dist; Fri, 13 Oct 2000 06:49:25 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e9DDnF305717 for ; Fri, 13 Oct 2000 06:49:16 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA19208 for ; Fri, 13 Oct 2000 06:49:16 -0700 (PDT) Received: from ish7.ericsson.com.au ([203.61.155.111]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA02609 for ; Fri, 13 Oct 2000 07:49:14 -0600 (MDT) Received: from brsi02.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id XAA20354; Fri, 13 Oct 2000 23:46:07 +1000 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id AAA07045; Sat, 14 Oct 2000 00:48:27 +1100 (EST) Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2650.21) id <4XFQPX3R>; Sat, 14 Oct 2000 00:48:35 +1100 Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A50C613C6B@eaubrnt018.epa.ericsson.se> From: "Hesham Soliman (EPA)" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Cc: ipng@sunroof.eng.sun.com Subject: RE: [MOBILE-IP] MIPv6 node location detection Date: Sat, 14 Oct 2000 00:48:35 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Sorry forgot to cc IPng > -----Original Message----- > From: Hesham Soliman (EPA) [SMTP:Hesham.Soliman@ERICSSON.COM.AU] > Sent: Saturday, 14 October 2000 12:42 > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [MOBILE-IP] MIPv6 node location detection > > > What is the difference between two advertisement below ? > > - Renumbered home link router advertisement > > - Router advertisement in a foreign link > > > > My question is why the mobile node don't just add the new address > > in MN's address list. How do the MN decide whether it start MIPv6 > > process or autoconfiguration process for renumbered home link address. > > What if the all home addresses in the list have expired before the MN > > get FA's router advertisement, can the MN still use the expired address > > record > > in it's system ? > > > => I think you're certainly asking the right question but > perhaps to the wrong mailing list :) > If I understand you correctly, you're saying that while the > MN is at Home, if a new advertisement is received with a new > prefix, how does it know that this is not another foreign subnet. > Well based on my rusty knowledge of ND and stateless address > configuration, it doesnt know. But I don't think that this is > strictly > a MIP issue. While you're at home MIP does not do anything > for you. So that's why I'll cc IPng on this to see if someone can > give you a better answer, or maybe I missed something here. > BTW FA's do not exist in MIPv6. > > > > > > > I also can't find RFC or draft which define exactly address list in a > > MIPv6 MN. A IPv6 node have a address list and every prefix has > lifetime. > > Please give me some advice on it. > > > > > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Oct 13 10:09:04 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) id e9DH7W705978 for ipng-dist; Fri, 13 Oct 2000 10:07:32 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e9DH7O305971 for ; Fri, 13 Oct 2000 10:07:24 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id e9DH6ug15370 for ipng@sunroof.eng.sun.com; Fri, 13 Oct 2000 10:06:56 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e9DFh5305832 for ; Fri, 13 Oct 2000 08:43:06 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA29091 for ; Fri, 13 Oct 2000 08:43:06 -0700 (PDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA03715 for ; Fri, 13 Oct 2000 09:43:04 -0600 (MDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (motgate 2.1) with ESMTP id IAA09289 for ; Fri, 13 Oct 2000 08:43:02 -0700 (MST)] Received: [from m-il06-r1.mot.com (m-il06-r1.mot.com [129.188.137.193]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id IAA19080 for ; Fri, 13 Oct 2000 08:43:02 -0700 (MST)] Received: from [140.101.173.9] by m-il06-r1.mot.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 13 Oct 2000 08:42:43 -0700 Received: (from root@localhost) by zorglub.crm.mot.com (8.8.8/8.8.8/crm-1.6) id RAA19621 for ipng@sunroof.eng.sun.com.DELIVER; Fri, 13 Oct 2000 17:42:40 +0200 (METDST) Received: from scooter.crm.mot.com (petrescu@riri.crm.mot.com [140.101.173.128]) by zorglub.crm.mot.com (8.8.8/8.8.8/crm-1.6) with ESMTP id RAA19537; Fri, 13 Oct 2000 17:42:38 +0200 (METDST) From: "Alexandru Petrescu" Cc: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM, ipng@sunroof.eng.sun.com Subject: Re: [MOBILE-IP] MIPv6 node location detection References: <001101c033ec$f1e096a0$a2388680@kwangwoon.ac.kr> <002c01c0350f$c6b4e7a0$a2388680@kwangwoon.ac.kr> Reply-To: "Alexandru Petrescu" Date: 13 Oct 2000 17:42:37 +0200 In-Reply-To: SungJin Lee's message of "Fri, 13 Oct 2000 21:19:03 +0900" Message-Id: Lines: 24 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk SungJin Lee writes: > What is the difference between two advertisement below ? > - Renumbered home link router advertisement > - Router advertisement in a foreign link I'm sharing your surprise there's no written differentiation. It is so striking that I imagine the authors have already thought of it and left it as an exercise :-) Let's say the MN wrongly considers the newly received RA as a movement, when in fact it was renumbering at home. It would first configure a CoA and default route, then try a BU to his HA. Now two things can happen here: (1) either the HA is not yet renumbered, so it will send a Binding Ack or (2) it has been renumbered and is no longer reachable. MN will use either the received Binding Ack (1) or HA Discovery (2) to find out that the HA's prefix is the same as the initial MN prefix (1) or as the CoA (2). Surprise, you're at home, so BU again, this time with zeroed lifetime to remove wrong cache entry. Thus, renumbering took place and not visiting. I think this would not work if home net and visited net both renumber at the same time and take each other's prefixes. Alex -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Oct 13 10:21:33 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) id e9DHJoU06037 for ipng-dist; Fri, 13 Oct 2000 10:19:50 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e9DHJe306030 for ; Fri, 13 Oct 2000 10:19:41 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA14597 for ; Fri, 13 Oct 2000 10:19:40 -0700 (PDT) Received: from sa-usa-sj-po.siliconaccess.com (w106.z064001180.sjc-ca.dsl.cnc.net [64.1.180.106]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA01974 for ; Fri, 13 Oct 2000 11:19:37 -0600 (MDT) Received: by sa-usa-sj-po.sanjose.siliconaccess.com with Internet Mail Service (5.5.2650.21) id <4W4APYXJ>; Fri, 13 Oct 2000 10:08:34 -0700 Message-ID: <39487C1D4449D41198960090270D93C00CB2BB@sa-can-ott-po.ottawa.siliconaccess.com> From: Mohit Goyal To: "'Bob Hinden'" , Thomas Eklund Cc: Thomas Narten , Erik.Nordmark@eng.sun.com, ipng@sunroof.eng.sun.com, scoya@ietf.org Subject: RE: Revised IPng Working Group Charter Date: Fri, 13 Oct 2000 10:20:27 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, Does a Ipv6 Router Requirements RFC or Internet-draft exist? Thanks, Mo -----Original Message----- From: Bob Hinden [mailto:hinden@iprg.nokia.com] Sent: Tuesday, October 10, 2000 2:12 AM To: Thomas Eklund Cc: Bob Hinden; Thomas Narten; Erik.Nordmark@eng.sun.com; ipng@sunroof.eng.sun.com; scoya@ietf.org Subject: RE: Revised IPng Working Group Charter Thomas, >I would like to see a "IPv6 router requirements" on the charts. Thanks. >Other important stuff is to define a MIB for mobileIPv6. This should be done in the Mobile IP w.g. who is developing Mobile IPv6. Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Oct 13 20:43:13 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) id e9E3fsa06833 for ipng-dist; Fri, 13 Oct 2000 20:41:54 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e9E3fh306826 for ; Fri, 13 Oct 2000 20:41:43 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id UAA11584 for ; Fri, 13 Oct 2000 20:41:43 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA10491 for ; Fri, 13 Oct 2000 20:41:42 -0700 (PDT) Received: from p7020-img-nt.cisco.com (sj-dial-3-15.cisco.com [171.68.180.16]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id UAA13905; Fri, 13 Oct 2000 20:41:37 -0700 (PDT) Message-Id: <5.0.0.25.2.20001013191004.02a845a0@flipper> X-Sender: fred@flipper X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 13 Oct 2000 19:22:49 -0600 To: SungJin Lee From: Fred Baker Subject: Re: [MOBILE-IP] MIPv6 node location detection Cc: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM, ipng@sunroof.eng.sun.com In-Reply-To: <001101c033ec$f1e096a0$a2388680@kwangwoon.ac.kr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I am not the most knowledgeable on the subject, and my betters may correct me. But I would think this has to be answered in the exchange with the Home Agent. First, the Mobile Node has a number of limitations on its knowledge. It doesn't know its own prefix beyond what it received in a router advertisement, for example - if the router advertisement has changed prefix, that may well mean that the device has changed subnet within its home domain and should just use that address, or as you suggest, it may mean that somebody is renumbering the network. Since it doesn't know the site prefix, it cannot distinguish between the home domain (which is larger than the prefix for a particular subnet) and a foreign domain. It also has a responsibility. It must keep the Home Agent apprised both of its own current address and its current care-of address. So if its address changes, or if a new address is added to its list on some interface, it is going to have to advise the Home Agent of that. It is from the Home Agent's response that it will determine what's happening. If the Home Agent expresses the opinion that it needs to use the COA, it probably does, and if the Home Agent thinks its address is just fine... Now, I haven't read the latest specifications to tell you how the Home Agent expresses that. But I think it is in that context that the information is going to have to be derived and communicated. At 10:37 AM 10/12/00 +0900, SungJin Lee wrote: >I got confisued while i was reading MIPv6 standards and >have a couple of question with cases like following. The >It is assumed that the MIPv6 node use stateless autoconfiguration. >Let me know if I lost some in MIPv6 and IPv6 RFC. > >Q.1 A MIPv6 node moved to foreign link. The MIPv6 node restarts > the system there and receives router advertisements with > foreign network prefix. > > How do the MIPv6 node detect if it is located in foreign link? > isn't it could be normal autoconfiguration as in the home llink? > >Q.2 A MIPv6 node located in it's home link. The node got an IP address > with stateless autoconfiguration. At a time the router changed the > home link > prefix and multicast the router advertisement with new prefix. > After the home link prefix ifetime expired or before the life time > expired, it received router advertisement with new prefix. > > Why doesn't the IPv6 node think it's located in foreign link when it > received? isn't it possible the IPv6 node to think it's moved to a > foreign > link and start MIPv6 process? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Oct 13 20:57:44 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) id e9E3uTg06893 for ipng-dist; Fri, 13 Oct 2000 20:56:29 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e9E3uK306886 for ; Fri, 13 Oct 2000 20:56:20 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id UAA12324 for ; Fri, 13 Oct 2000 20:56:19 -0700 (PDT) Received: from ish7.ericsson.com.au ([203.61.155.111]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA13724 for ; Fri, 13 Oct 2000 20:56:18 -0700 (PDT) Received: from brsi02.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id NAA02145 for ; Sat, 14 Oct 2000 13:53:10 +1000 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id OAA24059 for ; Sat, 14 Oct 2000 14:55:30 +1100 (EST) Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2650.21) id <4XFQQCJ0>; Sat, 14 Oct 2000 14:55:39 +1100 Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A50C613C7A@eaubrnt018.epa.ericsson.se> From: "Hesham Soliman (EPA)" To: ipng@sunroof.eng.sun.com Subject: FW: [MOBILE-IP] MIPv6 node location detection Date: Sat, 14 Oct 2000 14:55:38 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Forgot to cc IPng again ! > -----Original Message----- > From: Hesham Soliman (EPA) > Sent: Saturday, 14 October 2000 2:54 > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > Subject: RE: [MOBILE-IP] MIPv6 node location detection > > Hi Fred > I am not the most knowledgeable on the subject, and my betters may correct > me. But I would think this has to be answered in the exchange with the > Home > Agent. > > First, the Mobile Node has a number of limitations on its knowledge. It > doesn't know its own prefix beyond what it received in a router > advertisement, for example - if the router advertisement has changed > prefix, that may well mean that the device has changed subnet within its > home domain and should just use that address, or as you suggest, it may > mean that somebody is renumbering the network. Since it doesn't know the > site prefix, it cannot distinguish between the home domain (which is > larger > than the prefix for a particular subnet) and a foreign domain. > > It also has a responsibility. It must keep the Home Agent apprised both of > its own current address and its current care-of address. So if its address > changes, or if a new address is added to its list on some interface, it is > going to have to advise the Home Agent of that. > > It is from the Home Agent's response that it will determine what's > happening. If the Home Agent expresses the opinion that it needs to use > the > COA, it probably does, and if the Home Agent thinks its address is just > fine... > > Now, I haven't read the latest specifications to tell you how the Home > Agent expresses that. But I think it is in that context that the > information is going to have to be derived and communicated. > > => Well according to my memory there is no such expression > from the HA. Of course if the MN receives the new router > advertisement from the HA (router on the link), then it will > know that the default router is still the same and that there is > no need to move. But that is not a fault proof solution because > the link-local address may be duplicated between links. > > Another way of looking at it is that the "new" Ruter advertisement > should inform hosts that this subnet is "being renumbered". > I think this is a clean option. I don't think this should be a MIP > issue. MIPv6 solves the problem when the MN is away from > home, which is when MIPv6 is espected to solve it. > I would suggest that this is a ND-MIP interaction issue. > > Hesham > > At 10:37 AM 10/12/00 +0900, SungJin Lee wrote: > >I got confisued while i was reading MIPv6 standards and > >have a couple of question with cases like following. The > >It is assumed that the MIPv6 node use stateless autoconfiguration. > >Let me know if I lost some in MIPv6 and IPv6 RFC. > > > >Q.1 A MIPv6 node moved to foreign link. The MIPv6 node restarts > > the system there and receives router advertisements with > > foreign network prefix. > > > > How do the MIPv6 node detect if it is located in foreign link? > > isn't it could be normal autoconfiguration as in the home llink? > > > >Q.2 A MIPv6 node located in it's home link. The node got an IP address > > with stateless autoconfiguration. At a time the router changed > the > > home link > > prefix and multicast the router advertisement with new prefix. > > After the home link prefix ifetime expired or before the life > time > > expired, it received router advertisement with new prefix. > > > > Why doesn't the IPv6 node think it's located in foreign link when > it > > received? isn't it possible the IPv6 node to think it's moved to > a > > foreign > > link and start MIPv6 process? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Oct 15 17:30:25 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) id e9G0T8f07430 for ipng-dist; Sun, 15 Oct 2000 17:29:08 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e9G0Su307423 for ; Sun, 15 Oct 2000 17:28:56 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id RAA02848 for ; Sun, 15 Oct 2000 17:28:54 -0700 (PDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id RAA26828 for ; Sun, 15 Oct 2000 17:28:54 -0700 (PDT) Received: from 157.54.9.104 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 15 Oct 2000 17:28:52 -0700 (Pacific Daylight Time) Received: by INET-IMC-02 with Internet Mail Service (5.5.2651.58) id <45JL6ZZT>; Sun, 15 Oct 2000 17:28:51 -0700 Message-ID: From: Brian Zill To: "'Hesham Soliman (EPA)'" , ipng@sunroof.eng.sun.com, MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: RE: [MOBILE-IP] MIPv6 node location detection Date: Sun, 15 Oct 2000 17:28:44 -0700 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Another way of looking at it is that the "new" > > Ruter advertisement should inform hosts that > > this subnet is "being renumbered". I think > > this is a clean option. I don't think this > > should be a MIP issue. MIPv6 solves the problem > > when the MN is away from home, which is when > > MIPv6 is espected to solve it. I would suggest > > that this is a ND-MIP interaction issue. I don't think this is a general enough solution. In the common case, an administrator would renumber by adding the new prefix and marking the old prefix to time-out. A mobile node that returns home during the time-out delta could probably surmise that a renumbering was going on without needing an extra bit in the router advertisement. Yes, the extra bit could serve to aid those mobile nodes that don't come home until after the old prefix has expired, but how long does the router continue to advertise the "being renumbered" bit? At some point the administrator has to claim that the "being renumbered" state has finished, confusing any mobile nodes that don't return home until after that. And if some administrators never get around to turning the bit off, you'll have some networks in a state of perpetual renumberment. I think there's a better solution. Have mobile nodes attempt to treat every home agent they encounter as their home agent. A mobile node should only be able to successfully do so if the home agent actually is its home agent. Note that there has to be some sort of security authorization between the mobile node and the home agent or bad people visiting your link could steal one of your addresses (such authorization is required for the mobile node to securely update the home agent as to what its care-of-address is, so the authorization capability must exist). In other words, if you pass security, you're at home (or one of your homes, at any rate). Now the MIPv6 draft is a little weak regarding how this authorization should be done, but I think that's a problem for the mobile ip working group. --Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Oct 15 21:03:32 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) id e9G42Hv07594 for ipng-dist; Sun, 15 Oct 2000 21:02:17 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e9G427307587 for ; Sun, 15 Oct 2000 21:02:08 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id VAA19264 for ; Sun, 15 Oct 2000 21:02:06 -0700 (PDT) Received: from ish7.ericsson.com.au ([203.61.155.111]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA21174 for ; Sun, 15 Oct 2000 21:02:03 -0700 (PDT) Received: from brsi02.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id NAA22817; Mon, 16 Oct 2000 13:58:28 +1000 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id PAA22491; Mon, 16 Oct 2000 15:00:49 +1100 (EST) Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2650.21) id <4XFQRNWL>; Mon, 16 Oct 2000 15:00:59 +1100 Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A50C613C7C@eaubrnt018.epa.ericsson.se> From: "Hesham Soliman (EPA)" To: "'Brian Zill'" , ipng@sunroof.eng.sun.com, MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: RE: [MOBILE-IP] MIPv6 node location detection Date: Mon, 16 Oct 2000 15:00:48 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > Another way of looking at it is that the "new" > > > Ruter advertisement should inform hosts that > > > this subnet is "being renumbered". I think > > > this is a clean option. I don't think this > > > should be a MIP issue. MIPv6 solves the problem > > > when the MN is away from home, which is when > > > MIPv6 is espected to solve it. I would suggest > > > that this is a ND-MIP interaction issue. > > I don't think this is a general enough solution. In the common case, an > administrator would renumber by adding the new prefix and marking the old > prefix to time-out. A mobile node that returns home during the time-out > delta could probably surmise that a renumbering was going on without > needing > an extra bit in the router advertisement. Yes, the extra bit could serve > to > aid those mobile nodes that don't come home until after the old prefix has > expired, but how long does the router continue to advertise the "being > renumbered" bit? > => You can do it for the same duration that you advertise dual prefixes for or more. There are no hard rules for how long that should be and I think that's a good thing. I would argue that having a flag is better than simply just advertising two prefixes at the same time. If you have a flag then at least you're encouraging the MN's (or just any IPv6 node) to use the new prefix in establishing its new connection. On the other hand, advertising two prefixes may not necessarily mean that you are renumbering. Even if one of them has a shorter lifetime. > At some point the administrator has to claim that the > "being renumbered" state has finished, confusing any mobile nodes that > don't > return home until after that. And if some administrators never get around > to turning the bit off, you'll have some networks in a state of perpetual > renumberment. > => Well, the way of turning the flag off can be automated and set when you turn it on. I think that would depend on the implementation. As to the confusion if the MN returns after the flag is turned off, I think the confusion already exists, that's why we're having this discussion. Adding the flag will make it possible to reduce the confusion by keeping it on for a bit longer. When I mentioned a "being renumbered" flag I didn't mean that it MUST mean that. You could think of a flag that says "new prefix" and be included in the new prefix option. It certainly should be interpreted in a way that doesn't confuse hosts and make them think they're in a transient state. I'm not saying this is the best way, but it is certainly a stright forward solution that seems quite simple. > I think there's a better solution. Have mobile nodes attempt to treat > every > home agent they encounter as their home agent. A mobile node should only > be > able to successfully do so if the home agent actually is its home agent. > => I'm not quite sure if I understand this correctly. The MN will have a fixed home address with a certain prefix. If it asumes that it has a new Home address every time it hears an RA with the H flag set (for HA), that's ok but that doesn't solve the mobility problem for other Home addresses. It still needs to update the original "home" HA. The HA is only updated when the MN is in foreign subnet. What you're saing (if I understood it correctly) means the MN will have a new Home Address every time it moves to a new subnet. Again that's fine but it doesn't help the fixed home address and all the connections using it. > Note that there has to be some sort of security authorization between the > mobile node and the home agent or bad people visiting your link could > steal > one of your addresses (such authorization is required for the mobile node > to > securely update the home agent as to what its care-of-address is, so the > authorization capability must exist). In other words, if you pass > security, > you're at home (or one of your homes, at any rate). > => That authorisation only happens when you're in a foreign subnet. > Now the MIPv6 draft is > a little weak regarding how this authorization should be done, but I think > that's a problem for the mobile ip working group. > => I disagree here. MIPv6 BUs are secured using AH and that's mandatory. How a security asociation is established is not a MIP problem. It can be manually configured or dynamically using IKE. Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 16 04:44:02 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) id e9GBgf608011 for ipng-dist; Mon, 16 Oct 2000 04:42:41 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e9GBgW308004 for ; Mon, 16 Oct 2000 04:42:32 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id EAA01969 for ; Mon, 16 Oct 2000 04:42:31 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA05920 for ; Mon, 16 Oct 2000 05:42:29 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e9GBgIs23158; Mon, 16 Oct 2000 13:42:18 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id NAA12851; Mon, 16 Oct 2000 13:42:17 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id NAA62700; Mon, 16 Oct 2000 13:46:33 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200010161146.NAA62700@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Markku Savela" cc: ipng@sunroof.eng.sun.com Subject: Re: Time Exceeded and unknown extension headers before the ICMP header In-reply-to: Your message of Fri, 13 Oct 2000 11:16:43 +0300. <000001c034ed$eca677c0$e82815ac@hews0169nrc.research.nokia.com> Date: Mon, 16 Oct 2000 13:46:33 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: A router is supposed to send Time Exceeded ICMP when hoplimit goes to zero. However, it should not send this error, if the packet itself is an ICMP error, right? Now, in IPv6 I see a potential problem in implementing above. If there are unknown extension headers in front of the ICMP, as follows: IPv6 [ext. hdrs] ICMP6[Time Exceeded] ... If the router doesn't implement that particular extension header (for example AH, but also something totally new), how is it supposed to know that it should not generate a new ICMP Time Exceeded? (extension headers cannot be skipped without knowing them, as not all extension headers follow the same structure). => this was already discussed in this mailing list. The answer is to send the Time Exceeded if it is too expensive (or impossible with ESP) to know if the packet is an ICMP and to rely on ICMP rate limit in order to keep some bandwidth for other traffic. Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 16 05:30:49 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) id e9GCTT708094 for ipng-dist; Mon, 16 Oct 2000 05:29:29 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e9GCTI308087 for ; Mon, 16 Oct 2000 05:29:18 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id FAA24767 for ; Mon, 16 Oct 2000 05:29:19 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA16116 for ; Mon, 16 Oct 2000 05:29:18 -0700 (PDT) Received: from p7020-img-nt.cisco.com ([64.104.42.77]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id FAA22248; Mon, 16 Oct 2000 05:28:48 -0700 (PDT) Message-Id: <5.0.0.25.2.20001015183014.0283c5c0@flipper> X-Sender: fred@flipper X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Sun, 15 Oct 2000 18:44:27 -0700 To: SungJin Lee From: Fred Baker Subject: Re: [MOBILE-IP] MIPv6 node location detection Cc: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM, ipng@sunroof.eng.sun.com In-Reply-To: <001101c033ec$f1e096a0$a2388680@kwangwoon.ac.kr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I came up with the answer to your question. It takes some work, but it's there. Review draft-ietf-mobileip-ipv6-12.txt One the router advertisements (sections 4.1, 5.6, 5.7, etc), the routers tell you whether they are willing to be a home agent and/or a foreign agent. If no neighboring system is willing to be your home agent but there is a foreign agent, you are roaming. If there is someone willing to be a home agent but you cannot authenticate with him, your previous home agent remains your home agent, and you are roaming. If someone advertises that he will be your home agent and you can authenticate with him, you are at home. The one thing that bothered me as I read this was an implicit assumption, perhaps on my part and perhaps on the author's part, that the device has to somehow come in contact with its home agent as a neighboring device once in a while. I can think of a number of scenarios in which this may not be true - imagine a case where you have a telephone mailed to you on the road because the old one broke. You certainly want to be able to tell the new phone the old phone's information and have it stick. Or imagine a device which is permanently roaming - it never actually is at home. You would want to configure a home agent address somehow. I trust that in these cases the protocol is not required. At 09:37 AM 10/12/00 +0900, SungJin Lee wrote: >I got confisued while i was reading MIPv6 standards and >have a couple of question with cases like following. The >It is assumed that the MIPv6 node use stateless autoconfiguration. >Let me know if i lost some in MIPv6 and IPv6 RFC. > >Q.1 A MIPv6 node moved to foreign link. The MIPv6 node restarts > the system there and receives router advertisements with > foreign network prefix. > > How do the MIPv6 node detect if it is located in foreign link ? > isn't it could be normal autoconfiguration as in the home llink ? > >Q.2 A MIPv6 node located in it's home link. The node got an IP address > with stateless autoconfiguration. At a time the router changed > the home link > prefix and multicast the router advertisement with new prefix. > After the home link prefix ifetime expired or before the life time > expired, it received router advertisement with new prefix. > > Why doesn't the IPv6 node think it's located in foreign link when it > received ? isn't it possible the IPv6 node to think it's moved to > a foreign > link and start MIPv6 process ? > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 16 07:03:48 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) id e9GE23p08200 for ipng-dist; Mon, 16 Oct 2000 07:02:03 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e9GE1r308191 for ; Mon, 16 Oct 2000 07:01:53 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA04779 for ; Mon, 16 Oct 2000 07:01:54 -0700 (PDT) Received: from fsnt.future.futsoft.com ([203.197.140.35]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA01902 for ; Mon, 16 Oct 2000 07:01:51 -0700 (PDT) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Mon, 16 Oct 2000 19:34:44 +0530 Received: from vanithan ([10.0.14.22]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id TAA16987 for ; Mon, 16 Oct 2000 19:19:58 +0530 Reply-To: From: "Vanitha Neelamegam" To: Subject: RE: [MOBILE-IP] MIPv6 node location detection Date: Mon, 16 Oct 2000 19:29:41 +0530 Message-Id: <000101c03779$552a9b40$160e000a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <5.0.0.25.2.20001015183014.0283c5c0@flipper> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, Can anyone suggest me a IPV6 router (something like IPV4 Gated, which runs in Linux Environment) which can be used for interop testing. regards, Vanitha -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 16 10:49:07 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) id e9GHlaP08493 for ipng-dist; Mon, 16 Oct 2000 10:47:36 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e9GHlW308486 for ; Mon, 16 Oct 2000 10:47:32 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id e9GHl0O16263 for ipng@sunroof.eng.sun.com; Mon, 16 Oct 2000 10:47:00 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e9G6Xr307682 for ; Sun, 15 Oct 2000 23:33:53 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id XAA28847 for ; Sun, 15 Oct 2000 23:33:54 -0700 (PDT) Received: from mailweb8.rediffmail.com ([202.54.124.153]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id XAA15939 for ; Sun, 15 Oct 2000 23:33:43 -0700 (PDT) Received: (qmail 12245 invoked by uid 510); 16 Oct 2000 06:30:10 -0000 Date: 16 Oct 2000 06:30:10 -0000 Message-ID: <20001016063010.12244.qmail@mailweb8.rediffmail.com> MIME-Version: 1.0 To: "ipng@sunroof.eng.sun.com" Subject: IPV6 implementation From: "manivannan Muniandi" Content-ID: Content-type: text/plain Content-Description: Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, Can anyone suggest me an implementation (free downloadable, other than Linux and Windows NT) of IPv6 router which can be installed in Linux environment for interoperability testing . Regards, Vannan _________________________________________________ Get Your Free Email At, http://www.rediffmail.com For fabulous shopping deals visit: http://www.rediff.co.in/shopping/index.html -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 17 02:38:47 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) id e9H9bEo09392 for ipng-dist; Tue, 17 Oct 2000 02:37:14 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e9H9b3309385 for ; Tue, 17 Oct 2000 02:37:03 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id CAA19001 for ; Tue, 17 Oct 2000 02:37:03 -0700 (PDT) Received: from ish7.ericsson.com.au ([203.61.155.111]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA00867 for ; Tue, 17 Oct 2000 03:37:00 -0600 (MDT) Received: from brsi02.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id TAA21196; Tue, 17 Oct 2000 19:33:46 +1000 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id UAA29779; Tue, 17 Oct 2000 20:36:09 +1100 (EST) Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2650.21) id <4XFQS317>; Tue, 17 Oct 2000 20:36:18 +1100 Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A50C613C93@eaubrnt018.epa.ericsson.se> From: "Hesham Soliman (EPA)" To: "'Fred Baker'" Cc: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM, ipng@sunroof.eng.sun.com Subject: RE: [MOBILE-IP] MIPv6 node location detection Date: Tue, 17 Oct 2000 20:36:16 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I came up with the answer to your question. It takes some work, but it's > there. Review draft-ietf-mobileip-ipv6-12.txt > > One the router advertisements (sections 4.1, 5.6, 5.7, etc), the routers > tell you whether they are willing to be a home agent and/or a foreign > agent. If no neighboring system is willing to be your home agent but there > > is a foreign agent, you are roaming. If there is someone willing to be a > home agent but you cannot authenticate with him, your previous home agent > remains your home agent, and you are roaming. If someone advertises that > he > will be your home agent and you can authenticate with him, you are at > home. > => I'm not sure if I understand what you mean by the foreign agent. Perhaps you have another entity in mind ? Because the current MIPv6 draft does not have foreign agents. > The one thing that bothered me as I read this was an implicit assumption, > perhaps on my part and perhaps on the author's part, that the device has > to > somehow come in contact with its home agent as a neighboring device once > in > a while. I can think of a number of scenarios in which this may not be > true > - imagine a case where you have a telephone mailed to you on the road > because the old one broke. You certainly want to be able to tell the new > phone the old phone's information and have it stick. Or imagine a device > which is permanently roaming - it never actually is at home. You would > want > to configure a home agent address somehow. I trust that in these cases the > > protocol is not required. > => You never need to configure a Home Agent address. The current draft specifies a Dynamic Home Agent Discovery mechanism. All you need to configure is a Home Address. I believe MIPv6 can support the scenario you mentioned provided the MN knows its Home Address. Which is a reasonable assumption IMO. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 17 07:13:25 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) id e9HEC0l09596 for ipng-dist; Tue, 17 Oct 2000 07:12:00 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e9HEBo309589 for ; Tue, 17 Oct 2000 07:11:50 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA11647 for ; Tue, 17 Oct 2000 07:11:51 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA12053 for ; Tue, 17 Oct 2000 07:11:49 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e9HEB9s33678; Tue, 17 Oct 2000 16:11:11 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id QAA24722; Tue, 17 Oct 2000 16:11:08 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id QAA73291; Tue, 17 Oct 2000 16:15:30 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200010171415.QAA73291@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "John F. Leser" cc: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM, ipng@sunroof.eng.sun.com Subject: Re: [MOBILE-IP] MIPv6 node location detection In-reply-to: Your message of Fri, 13 Oct 2000 10:14:26 EDT. Date: Tue, 17 Oct 2000 16:15:29 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Reading through section 10.4 of the MIPv6 draft (version 12), I get the impression that: 1. Movement detection is not a simple problem to solve. The draft doesn't really specifiy what method should be used. => there are many different methods, some of them are (too) slow, some of them can detect movements when there is no movement, this can be a problem or not... I think we need to get results from fast/smart/... handoff special group and from implemention experiences. 2. Seeing an adverisement from a router with a different prefix is not a good way to detect movement. => I agree but the other way is not better. The preferred movement detection method seems to be loss of reachability of the MN's default router, => this is not good if there are more than one router and of course is very bad if the number of potential default routers is large enough... which is noticed through neighbor unreachability detection => which uses neighbor solicitations, not router solicitations ! and/or use of the router advertisement interval option. => this point should be added into neighbor discovery specs (ie. it is useful in general, not only for mobility). > > I also can't find RFC or draft which define exactly address list in a > > MIPv6 MN. A IPv6 node have a address list and every prefix has lifetime => in *theory* the list is the union of local prefixes and home prefixes, both are in router advertisements on the local link and through the tunnel with the home agent with the according lifetimes. In order to get the whole list ASAP someone suggested in this list that the home agent sends router advertisements to the MN when a home registration is done. The issue is what happens if the home link is renumbered when the MN is stopped. In fact this depends on how the MN knows its home prefix(es): - very stupid implementations believe the MN is started at home then the home prefixes will be prefixes of the first attached link: no problem with renumbering. - stupid implementations use a static config in order to know home prefixes then if the config is too old the MN will not be able to find its home link (and a home agent). - someone suggested in the list to use a name which can be updated when the home prefix is renumbered (but not renamed :-). It is a fine idea out of the scope of the mobile IPv6 draft. I think most implementations use the second way (static config)... An open question is what to do with DHCPv6? Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 17 07:16:28 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) id e9HEFYA09618 for ipng-dist; Tue, 17 Oct 2000 07:15:35 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e9HEFP309607 for ; Tue, 17 Oct 2000 07:15:25 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA27230 for ; Tue, 17 Oct 2000 07:15:25 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA12632 for ; Tue, 17 Oct 2000 08:15:24 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e9HEEls48614; Tue, 17 Oct 2000 16:14:47 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id QAA24848; Tue, 17 Oct 2000 16:14:47 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id QAA73331; Tue, 17 Oct 2000 16:19:08 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200010171419.QAA73331@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Alexandru Petrescu cc: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM, ipng@sunroof.eng.sun.com Subject: Re: [MOBILE-IP] MIPv6 node location detection In-reply-to: Your message of Fri, 13 Oct 2000 17:42:37 +0200. Date: Tue, 17 Oct 2000 16:19:08 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: I think this would not work if home net and visited net both renumber at the same time and take each other's prefixes. => this is explicitely forbidden because many things (not only mobility) will break if two prefixes are quickly swapped... Francis.Dupont@enst-bretagne.fr PS: prefixes are not ephemeral, default lifetimes are in days and renumbering "hold down" in months. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 17 07:25:51 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) id e9HEOOE09657 for ipng-dist; Tue, 17 Oct 2000 07:24:24 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e9HEOC309650 for ; Tue, 17 Oct 2000 07:24:13 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA01344 for ; Tue, 17 Oct 2000 07:24:13 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA17300 for ; Tue, 17 Oct 2000 08:24:07 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e9HENns48610; Tue, 17 Oct 2000 16:23:49 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id QAA25148; Tue, 17 Oct 2000 16:23:48 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id QAA73405; Tue, 17 Oct 2000 16:28:10 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200010171428.QAA73405@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Brian Zill cc: "'Hesham Soliman (EPA)'" , ipng@sunroof.eng.sun.com, MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Subject: Re: [MOBILE-IP] MIPv6 node location detection In-reply-to: Your message of Sun, 15 Oct 2000 17:28:44 PDT. Date: Tue, 17 Oct 2000 16:28:10 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Now the MIPv6 draft is a little weak regarding how this authorization should be done, but I think that's a problem for the mobile ip working group. => I disagree, MIPv6 mandates IPsec (AH in tunnel mode for authentication, integrity and replay protection). Perhaps there is a conflict between PPP authentication, DHCPv6, AAA and IPsec but this is not from a lack of protocols/tools (:-)... Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 17 15:28:30 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) id e9HMQl910315 for ipng-dist; Tue, 17 Oct 2000 15:26:47 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e9HMQZ310308 for ; Tue, 17 Oct 2000 15:26:36 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA05916 for ; Tue, 17 Oct 2000 15:26:36 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA20902 for ; Tue, 17 Oct 2000 15:26:35 -0700 (PDT) Received: from p7020-img-nt.cisco.com ([64.104.42.111]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id PAA06688; Tue, 17 Oct 2000 15:26:20 -0700 (PDT) Message-Id: <5.0.0.25.2.20001018071232.03508eb0@flipper> X-Sender: fred@flipper X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 18 Oct 2000 07:16:12 -0700 To: "Hesham Soliman (EPA)" From: Fred Baker Subject: RE: [MOBILE-IP] MIPv6 node location detection Cc: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM, ipng@sunroof.eng.sun.com In-Reply-To: <4B6BC00CD15FD2119E5F0008C7A419A50C613C93@eaubrnt018.epa.er icsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 08:36 PM 10/17/00 +1100, Hesham Soliman (EPA) wrote: >=> I'm not sure if I understand what you mean by the foreign agent. >Perhaps you have another entity in mind ? Because the current MIPv6 draft >does not have foreign agents. And therefore doesn't have a soft hand off option unless one can literally talk with both routers during the hand off. The Hierarchical Mobility draft suggests having an external system offer one of its addresses a second care-of address to provide this; to me, that's a foreign agent in disguise, and would be useful in that case. Sorry I was quick on the language. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 17 20:28:01 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) id e9I3QP810659 for ipng-dist; Tue, 17 Oct 2000 20:26:25 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e9I3QC310652 for ; Tue, 17 Oct 2000 20:26:12 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id UAA19213 for ; Tue, 17 Oct 2000 20:26:12 -0700 (PDT) Received: from ish7.ericsson.com.au ([203.61.155.111]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA19797 for ; Tue, 17 Oct 2000 20:26:10 -0700 (PDT) Received: from brsi02.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id NAA05775; Wed, 18 Oct 2000 13:22:51 +1000 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id OAA25557; Wed, 18 Oct 2000 14:25:15 +1100 (EST) Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2650.21) id <4XFQS0A3>; Wed, 18 Oct 2000 14:25:25 +1100 Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A50C613C98@eaubrnt018.epa.ericsson.se> From: "Hesham Soliman (EPA)" To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Cc: ipng@sunroof.eng.sun.com Subject: RE: [MOBILE-IP] MIPv6 node location detection Date: Wed, 18 Oct 2000 14:25:23 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > At 08:36 PM 10/17/00 +1100, Hesham Soliman (EPA) wrote: > >=> I'm not sure if I understand what you mean by the foreign agent. > >Perhaps you have another entity in mind ? Because the current MIPv6 > draft > >does not have foreign agents. > And therefore doesn't have a soft hand off option unless one can literally > > talk with both routers during the hand off. > => As far as I'm aware the term "soft handoff" is related to certain radio technologies that allow data to be received from multiple access points. This in no way implies receiving two separate traffic streams. It is an L2 feature that is used for handoffs and also as a mechanism for improving the received signal quality. IMO having foreign agents is not relevant for achieving soft handoffs. In fact the soft handoffs concept (as used today) is completely transparent to MIP (v4 and v6) or any L3 function as it happens on L2. > The Hierarchical Mobility draft > suggests having an external system offer one of its addresses a second > care-of address to provide this; to me, that's a foreign agent in > disguise, > and would be useful in that case. Sorry I was quick on the language. > => No problems. I obviously agree with comment on the usefulness of the MAP function. We avoided using the term FA in the draft because it is associated with the current understanding of FAs in IPv4. There certainly are differences. - FAs are mandatory on each link in MIPv4. MAPs are not. - FAs in MIPv4 perform other tasks like authentication which is a AAA function and need not be tied to mobility functions. - A MN can choose MAPs in the hierarchy based on various information in the MAP option. You can't do that with FAs. - MAPs can exist on any level of a hierarchy including first hop routers and are completely independant from each other. You can probably see more differences in the draft. What we tried to do is go away from the FA concept because we don't believe FAs ( as introduced in V4) are needed in IPv6. Perhaps some of the functions in FAs can be useful. But it seems unnecessary to copy and paste the functionality into IPv6. Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 18 02:40:47 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) id e9I9dPF10973 for ipng-dist; Wed, 18 Oct 2000 02:39:25 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e9I9dF310966 for ; Wed, 18 Oct 2000 02:39:16 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id CAA16459 for ; Wed, 18 Oct 2000 02:39:15 -0700 (PDT) Received: from smtp1.chello.se (smtp1.chello.se [193.150.195.10]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA21797 for ; Wed, 18 Oct 2000 02:39:13 -0700 (PDT) Received: from xelthomasek01 ([212.209.134.2]) by smtp1.chello.se (InterMail vK.4.02.00.00 201-232-116 license 13ed6d939a101f33a28aa8ad6d2fac65) with SMTP id <20001018093840.ICQA28958.smtp1@xelthomasek01>; Wed, 18 Oct 2000 11:38:40 +0200 Message-ID: <002e01c038e6$96cc9f80$6309000a@xelthomasek01> Reply-To: "Thomas Eklund" From: "Thomas Eklund" To: "Francis Dupont" , "John F. Leser" Cc: , References: <200010171415.QAA73291@givry.rennes.enst-bretagne.fr> Subject: Re: [MOBILE-IP] MIPv6 node location detection Date: Wed, 18 Oct 2000 11:34:18 +0200 Organization: Home MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi some commente regarding the movement detection algorithm. I agree that it might not be a good idea to tie your movement detection to when you are seeing an advertisement from a router with a different prefix. First of all - the statemachine for the movementdetection can be at two places - either in the 1) mobile node (which is the case today) or 2) it can sit in the network and then you could have network controlled handoff. To improve handoff you must make increase mobile IP's link-layer awarness. This is usually achived by listening on the field strengh or something similar of the radio link. The solution is different for every different radio link you have. Take 802.11 ethernet for instance, there you can associate every radio cell (and AP) to an IP subnet with a new prefix or you can associate several AP to an IP subnet (recomended). In case 1) you can associate every radio cell with a subnetprefix and you modify you movement detection algoritm (MDA) so that it builds up an internal list with prefixes and subnet and associated field strengh. For instance: General Parameters: Joning treshsholds: xxx dBm Leaving Treshholds: xxx dBm CoA Current Subnet Field strengh Active CoA CoA1 Prefix 1 xx dBm --- CoA2 Prefix 2 xx dBm Active CoA3 Prefix 3 xx dBm --- CoA4 Prefix 4 xx dBm --- CoA5 Prefix 5 xx dBm --- The intention is also to start bulding new CoA before you must switch over to a new AP which will make you handover quicker. You listens on the field strengh of the different radio cells or subnets and associate make you handover based on the field strengh. This approach could also be done from the AP or BS which would be a good aproach o a WAN radio like GSM or CDMA. Then the movement detection algorithm sits (it is not called that in GSM terms) in a BSC and in tells you to do you handover but in this case you would have to interupt that let mobile IP have that info and then mobile IP could be invoked in network initiated handoffs. This is nice on paper and would really optimize the radio network for IP but there is a lot of polotics here which can make it very difficult. You can also include QoS parameter in your handover design and you can make it very advanced. In other it is nothing in the spec that stops you from achieving very good handoffs. -- Thomas Eklund ----- Original Message ----- From: "Francis Dupont" To: "John F. Leser" Cc: ; Sent: Tuesday, October 17, 2000 4:15 PM Subject: Re: [MOBILE-IP] MIPv6 node location detection > In your previous mail you wrote: > > Reading through section 10.4 of the MIPv6 draft (version 12), I get the > impression that: > > 1. Movement detection is not a simple problem to solve. The draft > doesn't really specifiy what method should be used. > > => there are many different methods, some of them are (too) slow, > some of them can detect movements when there is no movement, this can > be a problem or not... I think we need to get results from fast/smart/... > handoff special group and from implemention experiences. > > 2. Seeing an adverisement from a router with a different prefix is not a > good way to detect movement. > > => I agree but the other way is not better. > > The preferred movement detection method seems to be loss of > reachability of the MN's default router, > > => this is not good if there are more than one router and of course > is very bad if the number of potential default routers is large enough... > > which is noticed through neighbor unreachability detection > > => which uses neighbor solicitations, not router solicitations ! > > and/or use of the router advertisement interval option. > > => this point should be added into neighbor discovery specs (ie. > it is useful in general, not only for mobility). > > > > I also can't find RFC or draft which define exactly address list in a > > > MIPv6 MN. A IPv6 node have a address list and every prefix has lifetime > > => in *theory* the list is the union of local prefixes and home prefixes, > both are in router advertisements on the local link and through the tunnel > with the home agent with the according lifetimes. In order to get the whole > list ASAP someone suggested in this list that the home agent sends router > advertisements to the MN when a home registration is done. > > The issue is what happens if the home link is renumbered when the MN is > stopped. In fact this depends on how the MN knows its home prefix(es): > - very stupid implementations believe the MN is started at home then > the home prefixes will be prefixes of the first attached link: no > problem with renumbering. > - stupid implementations use a static config in order to know home > prefixes then if the config is too old the MN will not be able to > find its home link (and a home agent). > - someone suggested in the list to use a name which can be updated > when the home prefix is renumbered (but not renamed :-). It is a > fine idea out of the scope of the mobile IPv6 draft. > I think most implementations use the second way (static config)... > > An open question is what to do with DHCPv6? > > Regards > > Francis.Dupont@enst-bretagne.fr > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 18 08:11:31 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) id e9IF9Z311280 for ipng-dist; Wed, 18 Oct 2000 08:09:35 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e9IF9Q311273 for ; Wed, 18 Oct 2000 08:09:26 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA21362 for ; Wed, 18 Oct 2000 08:09:25 -0700 (PDT) Received: from iol.unh.edu (mars.iol.unh.edu [132.177.121.222]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA20353 for ; Wed, 18 Oct 2000 09:09:24 -0600 (MDT) Received: from localhost (jfl@localhost) by iol.unh.edu (8.9.3/8.9.3) with ESMTP id LAA26480; Wed, 18 Oct 2000 11:10:50 -0400 (EDT) Date: Wed, 18 Oct 2000 11:10:50 -0400 From: "John F. Leser" To: Thomas Eklund cc: Francis Dupont , MOBILE-IP@STANDARDS.NORTELNETWORKS.COM, ipng@sunroof.eng.sun.com Subject: Re: [MOBILE-IP] MIPv6 node location detection In-Reply-To: <002e01c038e6$96cc9f80$6309000a@xelthomasek01> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 18 Oct 2000, Thomas Eklund wrote: > Hi some commente regarding the movement detection algorithm. > I agree that it might not be a good idea to tie your movement detection to > when you are seeing an advertisement from a router with a different prefix. > > First of all - the statemachine for the movementdetection can be at two > places - either in the 1) mobile node (which is the case today) or 2) it can > sit in the network and then you could have network controlled handoff. > > To improve handoff you must make increase mobile IP's link-layer awarness. > This is usually achived by listening on the field strengh or something > similar of the radio link. The solution is different for every different > radio link you have. [cut] I don't doubt that there are many ways the link layer could provide excellent movement detection. I think the issue here is how to provide some movement detection for MIPv6 without any special signalling from lower layers. I think you did touch on an important point - movement detection is really two problems - (1) detecting movement on to a link, and (2) detecting movement off of a link. If the mobile node is eager to move to new networks, then it is only critial that (1) take place quickly for smooth handoffs. Its somewhat less clear to me when (2) must take place, but it should happen eventually. With this in mind, I'd like to suggest this as an idea for movement detection: - Require that a home agent's router advertisements always contain all of the prefixes on the network that are valid for home or CO addresses. - Then, whenever a MN receives an RA with the H bit set, it will know with certainty whether that RA came from the current home or foreign network, or from some new network, based on whether the prefix of the MN's home or current CO address is advertised in the RA. This way, movement onto a new link is detected as soon as any home agent on that link sends an advertisement. - Whenever an RA is received indicating movement onto a new link, the MN transitions neigbor cache entry for the old default router(s) to stale, to accelerate unreachability detection. Of course, the danger here is that the network could be misconfigured so that home agents are not advertising all prefixes. This would be sub-optimal (mobility would be uses when it is not needed), but wouldn't prevent the mobile node from communicating. I'm curious what people think of this. ------------------------------------------------------------------- John Leser UNH InterOperability Lab IP/Routing Consortium Engineer Morse Hall, 39 College Rd, Room 332 Tel: (603) 862-0090 (8-5 EST) Durham, NH 03824-3525 Fax: (603) 862-1761 Web: www.iol.unh.edu ------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 18 09:18:27 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) id e9IGFdr11469 for ipng-dist; Wed, 18 Oct 2000 09:15:39 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e9IGFV311458 for ; Wed, 18 Oct 2000 09:15:32 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id e9IGEvE17239 for ipng@sunroof.eng.sun.com; Wed, 18 Oct 2000 09:14:57 -0700 (PDT) Received: from efra05-home.Germany.Sun.COM (efra05-home.Germany.Sun.COM [129.157.43.5] (may be forged)) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e9I7ux310894 for ; Wed, 18 Oct 2000 00:57:00 -0700 (PDT) Received: from vayne (muc-isdn-19 [129.157.164.119]) by efra05-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v1.9) with SMTP id JAA05639; Wed, 18 Oct 2000 09:56:49 +0200 (MET DST) Date: Wed, 18 Oct 2000 10:06:38 +0200 (MET DST) From: Erik Guttman Reply-To: Erik Guttman Subject: SVRLOC WG last call: draft-ietf-svrloc-ipv6-11.txt To: srvloc@srvloc.org, ipng@sunroof.eng.sun.com Cc: erik.guttman@germany.sun.com, Thomas Narten , Erik Nordmark Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The internet-draft "Service Location Protocol Modifications for IPv6" is entering WG last call again. Comments from the preceding WG last call gave rise to comments which required modifying the document. Please send comments to the srvloc@srvloc.org mailing list. This document concerns the IPNG WG so the last call is being announced on the IPNG mailing list. The last call period will end Nov 1, 2000. This document will be submitted to the IESG for consideration, to be advanced as a proposed standard RFC. Erik Guttman SVRLOC WG chair -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 18 15:48:34 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) id e9IMkr212415 for ipng-dist; Wed, 18 Oct 2000 15:46:53 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e9IMkh312408; Wed, 18 Oct 2000 15:46:44 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA11847; Wed, 18 Oct 2000 15:46:39 -0700 (PDT) Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA05586; Wed, 18 Oct 2000 15:46:38 -0700 (PDT) Received: from penelope.ecs.soton.ac.uk (penelope.ecs.soton.ac.uk [152.78.68.135]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id XAA19133; Wed, 18 Oct 2000 23:46:33 +0100 (BST) Received: from penelope (penelope [152.78.68.135]) by penelope.ecs.soton.ac.uk (8.9.1a/8.9.1) with ESMTP id XAA25692; Wed, 18 Oct 2000 23:46:32 +0100 (BST) Date: Wed, 18 Oct 2000 23:46:32 +0100 (BST) From: Tim Chown To: members@ipv6forum.com, ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, users@ipv6.org Subject: IPv6 2000: presentations are available online Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, Please excuse the "spam" but there is a new collection of IPv6 presentations available online, taken from the XIWT/IPv6 Forum event that is being held in Washington DC tomorrow and Friday. See http://www.ipv6forum.com and look for the XIWT logo. There are HTML, Powerpoint and PDF versions of most talks available; the rest will be added shortly. Many deployment and application areas are covered. If you want to go straight in to the presentations index, it's at: http://www.ipv6forum.com/navbar/events/xiwt00/presentations/ Cheers, Tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Oct 20 05:07:10 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) id e9KC5lp14293 for ipng-dist; Fri, 20 Oct 2000 05:05:47 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e9KC5c314286 for ; Fri, 20 Oct 2000 05:05:38 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id FAA05932 for ; Fri, 20 Oct 2000 05:05:36 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA05630 for ; Fri, 20 Oct 2000 05:05:34 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e9KC4qs32428; Fri, 20 Oct 2000 14:04:53 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id OAA16095; Fri, 20 Oct 2000 14:04:51 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id OAA89340; Fri, 20 Oct 2000 14:09:29 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200010201209.OAA89340@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "John F. Leser" cc: Thomas Eklund , MOBILE-IP@STANDARDS.NORTELNETWORKS.COM, ipng@sunroof.eng.sun.com Subject: Re: [MOBILE-IP] MIPv6 node location detection In-reply-to: Your message of Wed, 18 Oct 2000 11:10:50 EDT. Date: Fri, 20 Oct 2000 14:09:29 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: With this in mind, I'd like to suggest this as an idea for movement detection: - Require that a home agent's router advertisements always contain all of the prefixes on the network that are valid for home or CO addresses. => according to other messages your idea is to overload the meaning of the H flag with "this RA announces all the prefixes"... I don't think it is a good idea but if to know the number of prefixes (there are some optimizations where this info is needed) is very useful then why not a new extension with it in any RA? - Then, whenever a MN receives an RA with the H bit set, it will know with certainty whether that RA came from the current home or foreign network, or from some new network, based on whether the prefix of the MN's home or current CO address is advertised in the RA. This way, movement onto a new link is detected as soon as any home agent on that link sends an advertisement. => this is not protected against a rogue RA and doesn't work with overlapping cells (which seems to need the help of the layer two). - Whenever an RA is received indicating movement onto a new link, the MN transitions neigbor cache entry for the old default router(s) to stale, to accelerate unreachability detection. => move the state to incomplete is more aggressive (faster but more expensive if there is no real movement). I'm curious what people think of this. => I think to rely on RAs for movement detection is not very good because if this should be fast then the frequency of RAs has to be very high (ie. higher than reasonnable). And this is dedicated to a very special scenario (the cellular one) when there are many of them. In this list (mobile IP) many of us did shout that cellular != wireless != mobile, please add me... Regards Francis.Dupont@enst-bretagne.fr PS: the only very clear indication you can get from a RA is to receive an announce for the home prefix(es) where you are in visit. In other cases you can only suspect a movement. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Oct 20 13:38:09 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) id e9KKaCb15102 for ipng-dist; Fri, 20 Oct 2000 13:36:12 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e9KKa3315095 for ; Fri, 20 Oct 2000 13:36:04 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA01703 for ; Fri, 20 Oct 2000 13:36:01 -0700 (PDT) Received: from ziggy.stardust.com (ns.stardust.com [205.184.205.34]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA02306 for ; Fri, 20 Oct 2000 13:36:01 -0700 (PDT) Received: from pleiades (dhcp204-96.stardust.com [205.184.204.96]) by ziggy.stardust.com (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA16647; Fri, 20 Oct 2000 13:35:31 -0700 Message-Id: <3.0.5.32.20001020133530.013cdb20@stardust.com> X-Sender: jasonu@stardust.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 20 Oct 2000 13:35:30 -0700 To: ipng@sunroof.eng.sun.com From: Jason Utz Subject: Relevant Activities at upcoming iBANDatISPCON event Cc: martinh@stardust.com, scottm@stardust.com Mime-Version: 1.0 Content-Type: text/enriched; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Many people on this list have been attendees and participants in past iBAND events so I wanted to give you a heads up on the next iBAND, taking place with ISPCON at the San Jose Convention Center, Nov 8-10.=20 I'd also like to extend a special offer to members of this list since we've worked so closely with this group. For more event information, go to: http://events.stardust.com/iband Before October 25, 2000, you can sign up for the event, get all the sessions free in MP3 format=20 and get a $100 discount by going to https://events.stardust.com/iband/special/register_offer.htm and using the following registration code: IPV6 Highlights ---------- BOFs ---- * What's new in network processing and the CPIX Forum's role in it Colin Mick, CPIX Forum Steve Jacobson, RealNetworks * The Technical Needs of Content Peering Mark Day, Cisco Systems Brad Cain, Mirror Image Internet * Enabling QoS at the Network Edge Manickam "Sri" Sridhar, Sitara Networks * Policy-based Configuration Management Art Mellor, Gold Wire Technology * Riding the Wave of Streaming Video Bodhi Mukherjee, InfoValue Computing * Internet2 Russ Hobby, UC Davis iBAND Showcase - http://events.stardust.com/iband/showcase.htm The iBAND Showcase is the fourth in a series of networks engineered by members of the QoS Forum and exhibitors at the iBAND event -- It will feature: *Accelerated Application Services Tiered Services *Service Level Agreements (SLAs) *Intelligent Network Infrastructure *Service Management *Network Performance Tools Come and meet the people and companies who have worked together over a period of several months to reflect the latest products working in real networks. Companies involved:=20 *Agilent Technologies*CrossKeys*Hewlett-Packard*Ixia*ISPSoft*Intel*InterworkingLabs*I= P Highway*Nortel Networks *Orchestream*Riverstone Networks*Rockliffe systems*Spirent Communications=20 Come and experience first hand new intelligent infrastructure service and management capabilities in hosts, applications, routers, switches and network analysis tools. Engineered into several different network topologies, these interoperable products harness new protocol standards and core technologies. Keynote Descriptions * Content Delivery: A New World ofTechnology, Business & Value-Added Services Z. Alan Fink,Sr. Vice President & General Manager, Adero & Jim Ricotta,Senior Director, Marketing Cisco Systems Moving content around the Internet effectively and delivering the highest quality experience for information consumers has become an imperative for every Internet-driven organization. To align a growing number of technologies, products and services, and to accelerate the number of opportunities for participants in this new market, industry heavyweights have recently formed two new alliances: The Content Bridge Alliance and The Content Alliance. Forging new Internet standards, removing market barriers and creating new business opportunities are at the heart of these groups' activities. How should content be delivered and managed to provide the highest quality of service? What related services, technologies and peering agreements need to be addressed? Al Fink (Adero) and Jim Ricotta (Cisco Systems), founding members respectively of the Content Bridge Alliance and Content Alliance, will present their views on the technology and business challenges and opportunities that lie ahead for content providers, service providers and information consumers who lie on the content distribution value-chain * Internet Infrastructure: Why We Can't Just Paint Over the Cracks Judy Estrin, Chief Executive Officer, Packet Design, Inc.=20 The Internet continues to require advances in traffic management, scalability, performance and sophisticated content routing and management capabilities. But an increasing number of new Internet products and services are based on proprietary and/or point solutions that do not have the openess or scalability inherent in the original IP architecture. What long term implications do these approaches have for the future of the Internet? Do they undermine the traditional homogeneity of the Internet? Why, or should we care? And what do we need to do about it? In this keynote, Judy Estrin will address these questions and more and offer her own prescriptions for the long term health of the Internet's IP-based infrastructure.=20 * Creating, Provisioning and Managing IP Services Under Massive Commercial Pressures=20 Charles Muirhead, Founder, Orchestream and iGabriel.net The Internet has evolved from research facility to backbone of the new economy. Historically, fundamental Internet protocols were carefully agreed by standards bodies over many years but today's commercial pressures require huge infrastructure investment decisions daily. And today's Internet reality is one of many different technologies at multiple network layers. Given this flux, how do network managers best provision new services and manage their networks? Can we continue to innovate at breakneck speed with standards-based solutions? What does this all mean for buyers of network infrastructure products & services? In this keynote, Charles Muirhead will look at the new realities of product creation and infrastructure deployment.=20 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Oct 22 08:50:23 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) id e9MFn5h16084 for ipng-dist; Sun, 22 Oct 2000 08:49:05 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e9MFmv316077 for ; Sun, 22 Oct 2000 08:48:57 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA12501 for ; Sun, 22 Oct 2000 08:48:56 -0700 (PDT) Received: from lolo.logina.lt (logina.lt [195.22.177.68]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA21121 for ; Sun, 22 Oct 2000 08:48:55 -0700 (PDT) Received: by lolo.logina.lt (Postfix+IPv6, from userid 1001) id 9788737DC; Sun, 22 Oct 2000 17:48:51 +0200 (GMT-2) Received: from localhost (localhost [127.0.0.1]) by lolo.logina.lt (Postfix+IPv6) with ESMTP id 967561DE22; Sun, 22 Oct 2000 17:48:51 +0200 (GMT-2) Date: Sun, 22 Oct 2000 17:48:51 +0200 (GMT-2) From: Andrius Kasparavicius X-Sender: and@lolo.logina.lt To: users@ipv6.org Cc: ipng@sunroof.eng.sun.com Subject: The initial allocation IPv6 prefixes Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, where I can find current up-to-date "The initial allocation IPv6 prefixes" table? ------------------------- Kasparavicius Andrius -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 23 11:49:06 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) id e9NIkQQ16731 for ipng-dist; Mon, 23 Oct 2000 11:46:26 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e9NIk0316724 for ; Mon, 23 Oct 2000 11:46:00 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id e9NIjLc18639 for ipng@sunroof.eng.sun.com; Mon, 23 Oct 2000 11:45:21 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e9N0fY316248 for ; Sun, 22 Oct 2000 17:41:34 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id RAA08799 for ; Sun, 22 Oct 2000 17:41:34 -0700 (PDT) Received: from ktemail.kt.co.kr ([147.6.112.223]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA21933 for ; Sun, 22 Oct 2000 17:41:32 -0700 (PDT) Received: (from root@localhost) by ktemail.kt.co.kr (8.9.3/8.9.3) id JAA22840 for ipng@sunroof.eng.sun.com.procmail; Mon, 23 Oct 2000 09:30:21 +0900 (KST) Received: from kt.co.kr ([147.6.65.78]) by ktemail.kt.co.kr (8.9.3/8.9.3) with ESMTP id JAA12466; Mon, 23 Oct 2000 09:30:18 +0900 (KST) Message-ID: <39F389FC.7776E236@kt.co.kr> Date: Mon, 23 Oct 2000 09:44:44 +0900 From: ksb Reply-To: ksbn@kt.co.kr Organization: Korea Telecom X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Andrius Kasparavicius CC: users@ipv6.org, ipng@sunroof.eng.sun.com X-MAIL-AUTHOR: ksbn@kt.co.kr X-MAIL-MESSAGEID: snkfgyndcslipng Subject: Re: The initial allocation IPv6 prefixes References: Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Please see the following URL. http://www.dfn.de/service/ipv6/ipv6aggis.html Thank you. Andrius Kasparavicius wrote: > Hello, > where I can find current up-to-date "The initial allocation IPv6 > prefixes" table? > > ------------------------- > Kasparavicius Andrius > > --------------------------------------------------------------------- > The IPv6 Users Mailing List > Unsubscribe by sending "unsubscribe users" to majordomo@ipv6.org -- Kim, Sahng-Beom / Korea Telecom TEL : +82-42-870-8322 FAX : +82-42-870-8279 E-mail : ksbn@kt.co.kr -- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 23 11:50:09 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) id e9NIlvr16741 for ipng-dist; Mon, 23 Oct 2000 11:47:57 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e9NIlp316734 for ; Mon, 23 Oct 2000 11:47:51 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id e9NIlCU18668 for ipng@sunroof.eng.sun.com; Mon, 23 Oct 2000 11:47:12 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e9NCPZ316429 for ; Mon, 23 Oct 2000 05:25:35 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id FAA14060 for ; Mon, 23 Oct 2000 05:25:36 -0700 (PDT) Received: from indiainfo.com ([203.199.69.94]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA00351 for ; Mon, 23 Oct 2000 05:25:33 -0700 (PDT) Received: from [203.197.138.194] (account ) by indiainfo.com (CommuniGate Pro WebUser 3.4b1) with HTTP id 5058745; Mon, 23 Oct 2000 17:53:22 +0530 From: "Niveda Monyvannan" Subject: Subnet anycast address To: members@ipv6forum.com, users@ipv6.org, ipng@sunroof.eng.sun.com X-Mailer: CommuniGate Pro Web Mailer v.3.4b1 Date: Mon, 23 Oct 2000 17:53:22 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, IPv6 specs says that 'IPv6 router should take receive the packet destined to Subnet anycast address and the Subnet anycast address is nothing but the subnet prefix + interface ID as 0' When a packet with Destination address as ' Subnet anycast address' is generated? How a source of the packet in a subnet ensures that the packet is delivered to only one person in the subnet? Regards, Niveda ---------------------------------------- http://mail.indiainfo.com First you had 10MB of free mail space. Now you can send mails in your own language !!! -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 24 05:10:42 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) id e9OC92l17175 for ipng-dist; Tue, 24 Oct 2000 05:09:02 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e9OC8q317168 for ; Tue, 24 Oct 2000 05:08:53 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id FAA08879 for ; Tue, 24 Oct 2000 05:08:50 -0700 (PDT) Received: from mailhost.informatik.uni-bonn.de (olymp.informatik.uni-bonn.de [131.220.4.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA03968 for ; Tue, 24 Oct 2000 05:08:49 -0700 (PDT) Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by mailhost.informatik.uni-bonn.de (Postfix) with ESMTP id A17D962E9; Tue, 24 Oct 2000 14:08:48 +0200 (MET DST) Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.8.8+Sun/8.8.8) id OAA04052; Tue, 24 Oct 2000 14:08:47 +0200 (MET DST) Date: Tue, 24 Oct 2000 14:08:46 +0200 From: Ignatios Souvatzis To: Niveda Monyvannan Cc: members@ipv6forum.com, users@ipv6.org, ipng@sunroof.eng.sun.com Subject: Re: Subnet anycast address Message-ID: <20001024140846.A3930@theory.cs.uni-bonn.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from niveda@indiainfo.com on Mon, Oct 23, 2000 at 05:53:22PM +0530 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, Oct 23, 2000 at 05:53:22PM +0530, Niveda Monyvannan wrote: > IPv6 specs says that 'IPv6 router should take receive the > packet destined to Subnet anycast address and the Subnet anycast address > is nothing but the subnet prefix + interface ID as 0' No, it does not, at least the versions I have access to. What you describe is the subnet _router_ anycast address. > When a packet with Destination address as ' Subnet anycast address' is > generated? > > How a source of the packet in a subnet ensures that the packet is > delivered to only one person in the subnet? The source doesn't care. The router knows, when it sees such a packet, that it is for itself, and grabs it. Regards, -is -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 25 12:15:19 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) id e9PJDrN17950 for ipng-dist; Wed, 25 Oct 2000 12:13:53 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e9PJDi317943 for ; Wed, 25 Oct 2000 12:13:45 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA13324 for ; Wed, 25 Oct 2000 12:13:44 -0700 (PDT) Received: from chi6-1.relay.mail.uu.net (chi6-1.relay.mail.uu.net [199.171.54.98]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA00025 for ; Wed, 25 Oct 2000 12:13:40 -0700 (PDT) Received: from 21rst-century.com by chi6sosrv11.alter.net with ESMTP (peer crosschecked as: [63.105.122.50]) id QQjmlw15627; Wed, 25 Oct 2000 19:13:34 GMT Message-ID: <39F73055.31737D6F@21rst-century.com> Date: Wed, 25 Oct 2000 15:11:16 -0400 From: Marshall Eubanks Reply-To: tme@21rst-century.com X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC) X-Accept-Language: en,pdf MIME-Version: 1.0 To: rem-conf@es.net, ipng@sunroof.eng.sun.com Subject: Multicast RTP in IPv6 Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello; I hesitate to send to two lists at once, but both seem relevant. My apologies for duplicates. Does anyone know what the status of RTP/RTCP is in IPv6? I know that v6 is "born multicast enabled", but what is going to be required to actually use it with streaming audio / video ? This is going to be a major application with 3G wireless devices using IPv6, and we would like to start work on v6 compliant software. Regards Marshall Eubanks T.M. Eubanks Multicast Technologies, Inc 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@on-the-i.com tme@multicasttech.com http://www.on-the-i.com http://www.buzzwaves.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 25 13:57:49 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) id e9PKuHZ18019 for ipng-dist; Wed, 25 Oct 2000 13:56:17 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e9PKuD318012 for ; Wed, 25 Oct 2000 13:56:13 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id e9PKtWt21115 for ipng@sunroof.eng.sun.com; Wed, 25 Oct 2000 13:55:32 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e9PJx9317989 for ; Wed, 25 Oct 2000 12:59:10 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA13293 for ; Wed, 25 Oct 2000 12:58:54 -0700 (PDT) Received: from hafez.east.isi.edu (hafez.east.isi.edu [38.218.19.194]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA14502 for ; Wed, 25 Oct 2000 12:58:53 -0700 (PDT) Received: from hafez (csp@localhost) by hafez.east.isi.edu (8.11.0/8.11.0) with ESMTP id e9PJwf604773; Wed, 25 Oct 2000 15:58:41 -0400 Message-Id: <200010251958.e9PJwf604773@hafez.east.isi.edu> To: tme@21rst-century.com cc: rem-conf@es.net, ipng@sunroof.eng.sun.com Subject: Re: Multicast RTP in IPv6 In-Reply-To: Your message of "Wed, 25 Oct 2000 15:11:16 EDT." <39F73055.31737D6F@21rst-century.com> Date: Wed, 25 Oct 2000 15:58:41 -0400 From: Colin Perkins Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --> Marshall Eubanks writes: >Does anyone know what the status of RTP/RTCP is in IPv6? I know that >v6 is "born multicast enabled", but what is going to be required to >actually use it with streaming audio / video ? This is going to be a major >application with 3G wireless devices using IPv6, and we would like to start work on v6 >compliant software. No changes are required to RTP/RTCP to support IPv6, and there are a number of applications which support it already. See http://www-mice.cs.ucl.ac.uk/multimedia/software/rat/ for one open source implementation, there are others. Colin -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 25 18:59:56 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) id e9Q1vfo18233 for ipng-dist; Wed, 25 Oct 2000 18:57:41 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e9Q1vX318226 for ; Wed, 25 Oct 2000 18:57:33 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id SAA16874 for ; Wed, 25 Oct 2000 18:57:33 -0700 (PDT) Received: from rose.vnn.vn ([203.162.4.47]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA24056 for ; Wed, 25 Oct 2000 18:57:31 -0700 (PDT) Received: from fmail.vnn.vn ([202.167.114.118]) by rose.vnn.vn (Sun Internet Mail Server sims.4.0.1999.06.13.00.20) with ESMTPA id <0G30008BRLG9EN@rose.vnn.vn> for ipng@sunroof.eng.sun.com; Thu, 26 Oct 2000 08:57:47 +0700 (GMT) Date: Thu, 26 Oct 2000 08:56:06 +0700 From: Phan Huy Cuong Subject: Data To: ipng@sunroof.eng.sun.com Message-id: <39F78F36.C54F6B2E@fmail.vnn.vn> MIME-version: 1.0 X-Mailer: Mozilla 4.72 [en] (Win98; I) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, Any one have got data or document of processing change from IPv4 to IPv6. I need it for my project. Thanks for helping Huy Cuong Phan -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Oct 25 19:06:45 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) id e9Q25Dm18261 for ipng-dist; Wed, 25 Oct 2000 19:05:13 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e9Q254318254 for ; Wed, 25 Oct 2000 19:05:04 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id TAA07044 for ; Wed, 25 Oct 2000 19:05:04 -0700 (PDT) Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id TAA04646 for ; Wed, 25 Oct 2000 19:05:04 -0700 (PDT) Received: from rlfink.lbl.gov (Truckee.lbl.gov) [131.243.136.210] by mail1.es.net with esmtp (Exim 1.81 #2) id 13ocPf-0007bU-00; Wed, 25 Oct 2000 19:05:03 -0700 Message-Id: <5.0.0.25.0.20001025190350.02d20cd8@imap2.es.net> X-Sender: rlfink@imap2.es.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 25 Oct 2000 19:05:00 -0700 To: Phan Huy Cuong , ipng@sunroof.eng.sun.com From: Bob Fink Subject: Re: Data In-Reply-To: <39F78F36.C54F6B2E@fmail.vnn.vn> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 08:56 AM 10/26/2000 +0700, Phan Huy Cuong wrote: >Hello, >Any one have got data or document of processing change from IPv4 to >IPv6. I need it for my project. >Thanks for helping Take a look at: Abstract This document is a guide to the introduction of IPv6 in the IPv4 based Internet or Intranets. Several general issues to start IPv6 networking in a predominantly IPv4 world are discussed, such as IPv6 addresses, IPv6 DNS and routing issues. Short descriptions are given of the different transition tools and mechanisms that translate between IPv6 and IPv4 and/or tunnel IPv6 over IPv4. The remainder of this document describes how IPv6 can be introduced in various environments, such as ISPs, Internet Exchanges and end user environments. Suggestions are given on the use of the different translation and migration tools in each environment. Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Oct 27 03:40:18 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) id e9RAd7U19206 for ipng-dist; Fri, 27 Oct 2000 03:39:07 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e9RAcr319199 for ; Fri, 27 Oct 2000 03:38:53 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id DAA11624 for ; Fri, 27 Oct 2000 03:38:53 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA26990 for ; Fri, 27 Oct 2000 04:38:52 -0600 (MDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05670; Fri, 27 Oct 2000 06:38:51 -0400 (EDT) Message-Id: <200010271038.GAA05670@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipngwg-mld-mib-05.txt Date: Fri, 27 Oct 2000 06:38:50 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : IP Version 6 Management Information Base for the Multicast Listener Discovery Protocol Author(s) : B. Haberman, R. Worzella Filename : draft-ietf-ipngwg-mld-mib-05.txt Pages : 14 Date : 26-Oct-00 This document defines a portion of the Management Information Base (MIB) for use with network management protocols in Internet Protocol Version 6 internets. Specifically, this document is the MIB module that defines managed objects for implementations of the Multicast Listener Discovery Protocol [RFC2710]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-mld-mib-05.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-mld-mib-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-mld-mib-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001026141151.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-mld-mib-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-mld-mib-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001026141151.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Oct 27 03:40:29 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) id e9RAcYs19197 for ipng-dist; Fri, 27 Oct 2000 03:38:34 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e9RAcM319190 for ; Fri, 27 Oct 2000 03:38:23 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id DAA03565 for ; Fri, 27 Oct 2000 03:38:22 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA25405 for ; Fri, 27 Oct 2000 03:38:22 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05426; Fri, 27 Oct 2000 06:38:20 -0400 (EDT) Message-Id: <200010271038.GAA05426@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipngwg-rfc2553bis-01.txt Date: Fri, 27 Oct 2000 06:38:20 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Basic Socket Interface Extensions for IPv6 Author(s) : R. Gilligan, S. Thomson, J. Bound, W. Stevens Filename : draft-ietf-ipngwg-rfc2553bis-01.txt Pages : 31 Date : 26-Oct-00 The de facto standard application program interface (API) for TCP/IP applications is the 'sockets' interface. Although this API was developed for Unix in the early 1980s it has also been implemented on a wide variety of non-Unix systems. TCP/IP applications written using the sockets API have in the past enjoyed a high degree of portability and we would like the same portability with IPv6 applications. But changes are required to the sockets API to support IPv6 and this memo describes these changes. These include a new socket address structure to carry IPv6 addresses, new address conversion functions, and some new socket options. These extensions are designed to provide access to the basic IPv6 features required by TCP and UDP applications, including multicasting, while introducing a minimum of change into the system and providing complete compatibility for existing IPv4 applications. Additional extensions for advanced IPv6 features (raw sockets and access to the IPv6 extension headers) are defined in another document [4]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-rfc2553bis-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-rfc2553bis-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-rfc2553bis-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001026124906.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-rfc2553bis-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-rfc2553bis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001026124906.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Oct 27 09:57:24 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) id e9RGtjx19436 for ipng-dist; Fri, 27 Oct 2000 09:55:45 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e9RGtY319429 for ; Fri, 27 Oct 2000 09:55:34 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA07635 for ; Fri, 27 Oct 2000 09:55:34 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA27133 for ; Fri, 27 Oct 2000 09:55:34 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27314; Fri, 27 Oct 2000 12:55:23 -0400 (EDT) Message-Id: <200010271655.MAA27314@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , IANA Cc: Internet Architecture Board Cc: ipng@sunroof.eng.sun.com From: The IESG Subject: Protocol Action: IP Version 6 Management Information Base for the Multicast Listener Discovery Protocol to Proposed Standard Date: Fri, 27 Oct 2000 12:55:22 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has approved the Internet-Draft 'IP Version 6 Management Information Base for the Multicast Listener Discovery Protocol' as a Proposed Standard. This document is the product of the IPNG Working Group. The IESG contact persons are Erik Nordmark and Thomas Narten. Technical Summary This document defines a portion of the Management Information Base (MIB) for use with network management protocols in Internet Protocol Version 6 internets. Specifically, this document is the MIB module that defines managed objects for implementations of the Multicast Listener Discovery Protocol (RFC2710). Working Group Summary There was consensus within the WG for this document, and no issues were raised during IETF Last Call. Protocol Quality This protocol has been reviewed for the IESG by Juergen Schoenwaelder and Thomas Narten. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Oct 27 12:23:36 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) id e9RJMAZ19555 for ipng-dist; Fri, 27 Oct 2000 12:22:10 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e9RJM0319548; Fri, 27 Oct 2000 12:22:01 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA13660; Fri, 27 Oct 2000 12:21:58 -0700 (PDT) Received: from hunkular.glarp.com (hunkular.glarp.com [199.117.25.251]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA19021; Fri, 27 Oct 2000 13:21:49 -0600 (MDT) Received: from hunkular.glarp.com (localhost [127.0.0.1]) by hunkular.glarp.com (8.9.3/8.9.3) with ESMTP id NAA09586; Fri, 27 Oct 2000 13:21:37 -0600 (MDT) (envelope-from huntting@hunkular.glarp.com) Message-Id: <200010271921.NAA09586@hunkular.glarp.com> To: snap-users@kame.net, freebsd-questions@FreeBSD.ORG, ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: 6over4 for KAME (FreeBSD) Date: Fri, 27 Oct 2000 13:21:37 -0600 From: Brad Huntting Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Has anyone started writing a 6over4 (rfc2529) driver for KAME and/or FreeBSD? I have a pointer to a UCLA project called "Virtual Ethernet" by Quang Nguyen (no email address given), but it was written for the Inria stack and FreeBSD2. If there's nothing else available, I may use this as a guide. thanx, brad -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Oct 27 14:07:25 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) id e9RL5gg19660 for ipng-dist; Fri, 27 Oct 2000 14:05:43 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e9RL5c319653 for ; Fri, 27 Oct 2000 14:05:38 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id e9RL4uP23021 for ipng@sunroof.eng.sun.com; Fri, 27 Oct 2000 14:04:56 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e9RJVu319599; Fri, 27 Oct 2000 12:31:56 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA23685; Fri, 27 Oct 2000 12:31:56 -0700 (PDT) Received: from pogo.caustic.org (pogo.caustic.org [208.44.193.69]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA25835; Fri, 27 Oct 2000 13:31:54 -0600 (MDT) Received: from localhost (jan@localhost) by pogo.caustic.org (8.11.0/ignatz) with ESMTP id e9RJVlw78953; Fri, 27 Oct 2000 12:31:47 -0700 (PDT) Date: Fri, 27 Oct 2000 12:31:47 -0700 (PDT) From: "f.johan.beisser" To: Brad Huntting cc: snap-users@kame.net, freebsd-questions@FreeBSD.ORG, ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: 6over4 for KAME (FreeBSD) In-Reply-To: <200010271921.NAA09586@hunkular.glarp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk i'm not sure if this is what you mean, but: http://www.kfu.com/~nsayer/6to4/ also, i think that it is documented on http://www.kame.net. of course, i oculd very well be talking out of my butt. -- jan On Fri, 27 Oct 2000, Brad Huntting wrote: > > Has anyone started writing a 6over4 (rfc2529) driver for KAME and/or > FreeBSD? > > I have a pointer to a UCLA project called "Virtual Ethernet" by > Quang Nguyen (no email address given), but it was written for the > Inria stack and FreeBSD2. If there's nothing else available, I > may use this as a guide. > -------/ f. johan beisser /--------------------------------------+ http://caustic.org/~jan jan@caustic.org "Never laugh at someone until you've walked a mile in their shoes. Then laugh. For you are a mile away, and you have their shoes." -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Oct 27 14:20:34 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) id e9RLIw519718 for ipng-dist; Fri, 27 Oct 2000 14:18:58 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e9RLII319711; Fri, 27 Oct 2000 14:18:19 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA19207; Fri, 27 Oct 2000 14:18:19 -0700 (PDT) Received: from minuet.das.harvard.edu (minuet.das.harvard.edu [140.247.50.251]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA22172; Fri, 27 Oct 2000 14:18:18 -0700 (PDT) Received: from endor.eas.harvard.edu (endor.harvard.edu [128.103.50.55]) by minuet.das.harvard.edu (8.9.1/8.9.1) with ESMTP id RAA26395; Fri, 27 Oct 2000 17:18:03 -0400 (EDT) From: Dan Lanciani Received: (from ddl@localhost) by endor.eas.harvard.edu (8.8.8/8.8.8) id RAA13943; Fri, 27 Oct 2000 17:18:02 -0400 (EDT) Date: Fri, 27 Oct 2000 17:18:02 -0400 (EDT) Message-Id: <200010272118.RAA13943@endor.eas.harvard.edu> To: huntting@hunkular.glarp.com, jan@caustic.org Subject: Re: 6over4 for KAME (FreeBSD) Cc: freebsd-questions@FreeBSD.ORG, ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, snap-users@kame.net Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk |i'm not sure if this is what you mean, but: | |http://www.kfu.com/~nsayer/6to4/ I think that might not be what he meant. :) However, speaking of 6to4, how accepting are the 6bone sites of 0x2002 prefix addresses? At first glance, www.6bone.net and www.kame.net are happy to respond to packets from 6to4 addresses, but some of the public IPv6 "tool" web sites don't have a route to any 6to4 relay at all (or at least that seems to be the case). IMHO, 6to4 is a great way to encourage IPv6 deployment (especially with Microsoft pushing it), but the addresses need to be treated as more than a temporary hack if people are to commit. (Alternately, I suppose 6to4 addresses could simply overtake "real" addresses. :) Dan Lanciani ddl@harvard.edu -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Oct 27 14:48:06 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) id e9RLkZx19848 for ipng-dist; Fri, 27 Oct 2000 14:46:35 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e9RLkQ319841; Fri, 27 Oct 2000 14:46:27 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA21483; Fri, 27 Oct 2000 14:46:27 -0700 (PDT) Received: from hunkular.glarp.com (hunkular.glarp.com [199.117.25.251]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA27530; Fri, 27 Oct 2000 14:46:27 -0700 (PDT) Received: from hunkular.glarp.com (localhost [127.0.0.1]) by hunkular.glarp.com (8.9.3/8.9.3) with ESMTP id PAA17119; Fri, 27 Oct 2000 15:46:26 -0600 (MDT) (envelope-from huntting@hunkular.glarp.com) Message-Id: <200010272146.PAA17119@hunkular.glarp.com> To: "f.johan.beisser" cc: ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, cmj@3Com.com Subject: An IPv4 anycast address for 6to4<->6bone gateways In-Reply-To: Your message of "Fri, 27 Oct 2000 12:31:47 PDT." Date: Fri, 27 Oct 2000 15:46:25 -0600 From: Brad Huntting Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > http://www.kfu.com/~nsayer/6to4/ Actually this web page brings up another issue that a freind and I were discussing just yesterday. Anyone who's actually tried to use 6to4 (2002::/16) has probably noticed that they need a default route to reach the 6bone. But even assuming you actually find such a router it is almost always on the far side of the Internet; which means that your packets get to take the scenic route on their way to the 6bone. One simple solution to this would seem to be to use a well known IPv4 "anycast" address (call it "a.b.c.d" for now) for all 6to4 gateways. In this way, anyone using 6to4 could reliably use 2002:(a.b.c.d)::1 (actual IPv6 address syntax will vary) as a default route to the 6bone. 6to4 gateways would advertise to the their IPv4 peers that they have a route for "a.b.c.d". And for their IPv6 peers (the 6bone) they can advertise a route for 2002::/16. Does anyone see a problem with this? I dont suppose there's already a block of IPv4 address space set aside for anycast? brad -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Oct 27 14:59:52 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) id e9RLwID19898 for ipng-dist; Fri, 27 Oct 2000 14:58:18 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e9RLw7319891 for ; Fri, 27 Oct 2000 14:58:07 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA24991 for ; Fri, 27 Oct 2000 14:58:08 -0700 (PDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id OAA03956 for ; Fri, 27 Oct 2000 14:58:07 -0700 (PDT) Received: from 157.54.9.104 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 27 Oct 2000 14:58:01 -0700 (Pacific Daylight Time) Received: by INET-IMC-02 with Internet Mail Service (5.5.2651.58) id ; Fri, 27 Oct 2000 14:40:48 -0700 Message-ID: From: Brian Zill To: "'f.johan.beisser'" , Brad Huntting Cc: snap-users@kame.net, freebsd-questions@FreeBSD.ORG, ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: RE: 6over4 for KAME (FreeBSD) Date: Fri, 27 Oct 2000 14:40:23 -0700 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk 6to4 and 6over4, while having unfortunately similar names, are quite different things. 6to4 is a form of automatic IPv6 tunneling over IPv4. The IPv4 address of the "home" end of the tunnel is encoded into the IPv6 prefix. See draft-ietf-ngtrans-6to4-07.txt. 6over4 is another IPv6 over "foo", where "foo" in this case is a multicast-enabled IPv4 network, instead of say Ethernet or FDDI. See RFC 2529. My recollection is that an implementation of 6over4 for some BSD flavor exists, since I recall someone performing some interoperability testing between our implementation and that implementation. UCLA sounds familiar. Aren't two interoperating implementations a requirement for Proposed Standard? (RFC 2529 is at PS) I'm not aware of any others offhand, but it wouldn't surprise me if there were some. --Brian > -----Original Message----- > From: f.johan.beisser [mailto:jan@caustic.org] > Sent: Friday, 27 October, 2000 12:32 > To: Brad Huntting > Cc: snap-users@kame.net; freebsd-questions@FreeBSD.ORG; > ngtrans@sunroof.eng.sun.com; ipng@sunroof.eng.sun.com > Subject: Re: 6over4 for KAME (FreeBSD) > > > > i'm not sure if this is what you mean, but: > > http://www.kfu.com/~nsayer/6to4/ > > also, i think that it is documented on http://www.kame.net. > > of course, i oculd very well be talking out of my butt. > > -- jan > > > > On Fri, 27 Oct 2000, Brad Huntting wrote: > > > > > Has anyone started writing a 6over4 (rfc2529) driver for KAME and/or > > FreeBSD? > > > > I have a pointer to a UCLA project called "Virtual Ethernet" by > > Quang Nguyen (no email address given), but it was written for the > > Inria stack and FreeBSD2. If there's nothing else available, I > > may use this as a guide. > > > > > -------/ f. johan beisser /--------------------------------------+ > http://caustic.org/~jan jan@caustic.org > "Never laugh at someone until you've walked a mile in their > shoes. Then laugh. For you are a mile away, and > you have their shoes." > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Oct 27 16:24:31 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) id e9RNNCB20008 for ipng-dist; Fri, 27 Oct 2000 16:23:12 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e9RNLM319963; Fri, 27 Oct 2000 16:21:22 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA16454; Fri, 27 Oct 2000 16:21:22 -0700 (PDT) Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA07676; Fri, 27 Oct 2000 16:21:21 -0700 (PDT) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600); Fri, 27 Oct 2000 16:01:03 -0700 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 27 Oct 2000 16:01:42 -0700 (Pacific Daylight Time) Received: from DINO.platinum.corp.microsoft.com ([172.30.236.100]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Fri, 27 Oct 2000 16:01:42 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C04069.DEC25102" Subject: RE: 6over4 for KAME (FreeBSD) Date: Fri, 27 Oct 2000 16:01:41 -0700 Message-ID: <5B90AD65A9E8934987DB0C8C0762657401D42BFD@DF-BOWWOW.platinum.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 6over4 for KAME (FreeBSD) Thread-Index: AcBAYYRv2TnjaFLORzOg22lBbUiJXAACEImQ From: "Dave Thaler" To: "Brian Zill" , "f.johan.beisser" , "Brad Huntting" Cc: , , , X-OriginalArrivalTime: 27 Oct 2000 23:01:42.0392 (UTC) FILETIME=[DF075F80:01C04069] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C04069.DEC25102 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Brian Zill writes: > Aren't two interoperating implementations a requirement for Proposed > Standard? No, I believe it's a requirement for *Draft* Standard. -Dave ------_=_NextPart_001_01C04069.DEC25102 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: 6over4 for KAME (FreeBSD)

Brian Zill writes:
> Aren't two interoperating implementations a = requirement for Proposed
> Standard?

No, I believe it's a requirement for *Draft* = Standard.

-Dave

------_=_NextPart_001_01C04069.DEC25102-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Oct 27 16:24:45 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) id e9RNMta19997 for ipng-dist; Fri, 27 Oct 2000 16:22:55 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e9RNLM319964; Fri, 27 Oct 2000 16:21:22 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA16460; Fri, 27 Oct 2000 16:21:22 -0700 (PDT) Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA07682; Fri, 27 Oct 2000 16:21:22 -0700 (PDT) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600); Fri, 27 Oct 2000 15:59:54 -0700 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 27 Oct 2000 16:00:33 -0700 (Pacific Daylight Time) Received: from DINO.platinum.corp.microsoft.com ([172.30.236.100]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Fri, 27 Oct 2000 16:00:33 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C04069.B595E605" Subject: RE: (ngtrans) An IPv4 anycast address for 6to4<->6bone gateways Date: Fri, 27 Oct 2000 16:00:32 -0700 Message-ID: <5B90AD65A9E8934987DB0C8C0762657401D42BFC@DF-BOWWOW.platinum.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: (ngtrans) An IPv4 anycast address for 6to4<->6bone gateways Thread-Index: AcBAX8/yFxWAnLZoTDWo6dNJtNiVywACYDig From: "Dave Thaler" To: "Brad Huntting" , "f.johan.beisser" Cc: , , X-OriginalArrivalTime: 27 Oct 2000 23:00:33.0268 (UTC) FILETIME=[B5D3E340:01C04069] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C04069.B595E605 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This was mentioned in the NGtrans meeting in Pittsburgh,=20 and no such an anycast address doesn't currently exist. What would be needed would be to get a prefix short=20 enough to pass the prefix length filters in the Internet, and then just use 1 of the addresses in that large prefix. (Some would argue that having packets take the scenic route as you describe is desirable, however.) -Dave > -----Original Message----- > From: Brad Huntting [mailto:huntting@hunkular.glarp.com] > Sent: Friday, October 27, 2000 2:46 PM > To: f.johan.beisser > Cc: ngtrans@sunroof.eng.sun.com; ipng@sunroof.eng.sun.com;=20 > cmj@3Com.com > Subject: (ngtrans) An IPv4 anycast address for 6to4<->6bone gateways >=20 >=20 >=20 > > http://www.kfu.com/~nsayer/6to4/ >=20 > Actually this web page brings up another issue that a freind and > I were discussing just yesterday. Anyone who's actually tried to > use 6to4 (2002::/16) has probably noticed that they need a default > route to reach the 6bone. But even assuming you actually find such > a router it is almost always on the far side of the Internet; which > means that your packets get to take the scenic route on their way > to the 6bone. >=20 > One simple solution to this would seem to be to use a well known > IPv4 "anycast" address (call it "a.b.c.d" for now) for all 6to4 > gateways. >=20 > In this way, anyone using 6to4 could reliably use 2002:(a.b.c.d)::1 > (actual IPv6 address syntax will vary) as a default route to the > 6bone. >=20 > 6to4 gateways would advertise to the their IPv4 peers that they > have a route for "a.b.c.d". And for their IPv6 peers (the 6bone) > they can advertise a route for 2002::/16. >=20 > Does anyone see a problem with this? I dont suppose there's already > a block of IPv4 address space set aside for anycast? >=20 >=20 > brad ------_=_NextPart_001_01C04069.B595E605 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: (ngtrans) An IPv4 anycast address for 6to4<->6bone = gateways

This was mentioned in the NGtrans meeting in = Pittsburgh,
and no such an anycast address doesn't currently = exist.

What would be needed would be to get a prefix short =
enough to pass the prefix length filters in the = Internet,
and then just use 1 of the addresses in that large = prefix.

(Some would argue that having packets take the = scenic
route as you describe is desirable, however.)

-Dave

> -----Original Message-----
> From: Brad Huntting [mailto:huntting@hunkular.glar= p.com]
> Sent: Friday, October 27, 2000 2:46 PM
> To: f.johan.beisser
> Cc: ngtrans@sunroof.eng.sun.com; = ipng@sunroof.eng.sun.com;
> cmj@3Com.com
> Subject: (ngtrans) An IPv4 anycast address for = 6to4<->6bone gateways
>
>
>
> > http://www.kfu.com/~nsayer/6to4= /
>
> Actually this web page brings up another issue = that a freind and
> I were discussing just yesterday.  Anyone = who's actually tried to
> use 6to4 (2002::/16) has probably noticed that = they need a default
> route to reach the 6bone.  But even = assuming you actually find such
> a router it is almost always on the far side of = the Internet; which
> means that your packets get to take the scenic = route on their way
> to the 6bone.
>
> One simple solution to this would seem to be to = use a well known
> IPv4 "anycast" address (call it = "a.b.c.d" for now) for all 6to4
> gateways.
>
> In this way, anyone using 6to4 could reliably = use 2002:(a.b.c.d)::1
> (actual IPv6 address syntax will vary) as a = default route to the
> 6bone.
>
> 6to4 gateways would advertise to the their IPv4 = peers that they
> have a route for "a.b.c.d".  And = for their IPv6 peers (the 6bone)
> they can advertise a route for 2002::/16.
>
> Does anyone see a problem with this?  I = dont suppose there's already
> a block of IPv4 address space set aside for = anycast?
>
>
> brad

------_=_NextPart_001_01C04069.B595E605-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Oct 27 18:14:57 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) id e9S1DZP20139 for ipng-dist; Fri, 27 Oct 2000 18:13:35 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e9S1DQ320132 for ; Fri, 27 Oct 2000 18:13:26 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id SAA09004 for ; Fri, 27 Oct 2000 18:13:27 -0700 (PDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id SAA26932 for ; Fri, 27 Oct 2000 18:13:26 -0700 (PDT) Received: from 157.54.9.104 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 27 Oct 2000 18:13:22 -0700 (Pacific Daylight Time) Received: by INET-IMC-02 with Internet Mail Service (5.5.2651.58) id ; Fri, 27 Oct 2000 18:11:46 -0700 Message-ID: From: Christian Huitema To: "'Brad Huntting'" , "f.johan.beisser" Cc: ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, cmj@3Com.com Subject: RE: An IPv4 anycast address for 6to4<->6bone gateways Date: Fri, 27 Oct 2000 18:11:26 -0700 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Actually, what you want is to reserve sufficiently large IP address prefix, so that it will be accepted without questions by BGP routers -- at least a /19; a class B would be nice; in fact, if an address rich institution would donate a class B for that purpose, that would be even better; asking the IANA to reserve 191.255/16 for that purpose would also look cool. It would also be useful to dedicate an IPv4 AS number to that purpose. The IPv6 routers that have a complete access to both IPv6 and IPv4 would announce the corresponding prefix in their local IGP, as a route to an external network. The ASes that run such routers and are willing to provide access to the v6 network would announce a path to the v6 AS and to the 6to4 prefix using BGP; they could easily use the existing structure of peering and transit agreement to control to whom they are willing to provide service. The whole v6 network will appear to v4 as a single AS, with lots of peering points all over the place. The 6to4 gateways would then send use an address under the 6to4 prefix as a default route for reaching v6 packets. It will normally reach the service provided by their ISP, or by the closest ISP according to inter-domain routing. This scheme has many advantages. It is simple to implement in 6to4 gateways, it allows ISP to control to whom they are providing service, it allows for independent deployments of gateways to the 6Bone and the v6 network by multiple ISPs, it allows for scaling by deploying a large number of "peering points." In the acknowledgement section: I believe that scheme was first proposed by Randy Bush. -- Christian Huitema > -----Original Message----- > From: Brad Huntting [mailto:huntting@hunkular.glarp.com] > Sent: Friday, October 27, 2000 2:46 PM > To: f.johan.beisser > Cc: ngtrans@sunroof.eng.sun.com; ipng@sunroof.eng.sun.com; > cmj@3Com.com > Subject: An IPv4 anycast address for 6to4<->6bone gateways > > > > > http://www.kfu.com/~nsayer/6to4/ > > Actually this web page brings up another issue that a freind and > I were discussing just yesterday. Anyone who's actually tried to > use 6to4 (2002::/16) has probably noticed that they need a default > route to reach the 6bone. But even assuming you actually find such > a router it is almost always on the far side of the Internet; which > means that your packets get to take the scenic route on their way > to the 6bone. > > One simple solution to this would seem to be to use a well known > IPv4 "anycast" address (call it "a.b.c.d" for now) for all 6to4 > gateways. > > In this way, anyone using 6to4 could reliably use 2002:(a.b.c.d)::1 > (actual IPv6 address syntax will vary) as a default route to the > 6bone. > > 6to4 gateways would advertise to the their IPv4 peers that they > have a route for "a.b.c.d". And for their IPv6 peers (the 6bone) > they can advertise a route for 2002::/16. > > Does anyone see a problem with this? I dont suppose there's already > a block of IPv4 address space set aside for anycast? > > > brad > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Oct 27 18:44:22 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) id e9S1h0d20198 for ipng-dist; Fri, 27 Oct 2000 18:43:00 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e9S1gp320191; Fri, 27 Oct 2000 18:42:51 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id SAA19037; Fri, 27 Oct 2000 18:42:52 -0700 (PDT) Received: from minuet.das.harvard.edu (minuet.das.harvard.edu [140.247.50.251]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA23383; Fri, 27 Oct 2000 18:42:51 -0700 (PDT) Received: from endor.deas.harvard.edu (endor.harvard.edu [128.103.50.55]) by minuet.das.harvard.edu (8.9.1/8.9.1) with ESMTP id VAA29470; Fri, 27 Oct 2000 21:42:45 -0400 (EDT) From: Dan Lanciani Received: (from ddl@localhost) by endor.deas.harvard.edu (8.8.8/8.8.8) id VAA14538; Fri, 27 Oct 2000 21:42:44 -0400 (EDT) Date: Fri, 27 Oct 2000 21:42:44 -0400 (EDT) Message-Id: <200010280142.VAA14538@endor.deas.harvard.edu> To: dthaler@Exchange.Microsoft.com, huntting@hunkular.glarp.com, jan@caustic.org Subject: RE: (ngtrans) An IPv4 anycast address for 6to4<->6bone gateways Cc: cmj@3Com.com, ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk |What would be needed would be to get a prefix short |enough to pass the prefix length filters in the Internet, |and then just use 1 of the addresses in that large prefix. Or for less waste, somebody could just donate a pre-CIDR class-C. Are there any ISPs of any significance that don't exempt them from the prefix length constraints? |(Some would argue that having packets take the scenic |route as you describe is desirable, however.) What is the argument for this? Dan Lanciani ddl@harvard.edu -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Oct 28 01:28:01 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) id e9S8Q7r20375 for ipng-dist; Sat, 28 Oct 2000 01:26:07 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e9S8Pq320368; Sat, 28 Oct 2000 01:25:53 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id BAA14671; Sat, 28 Oct 2000 01:25:51 -0700 (PDT) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA20149; Sat, 28 Oct 2000 01:25:50 -0700 (PDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id EAA09946; Sat, 28 Oct 2000 04:25:40 -0400 (EDT) Message-Id: <200010280825.EAA09946@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Brad Huntting cc: "f.johan.beisser" , ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, cmj@3Com.com Subject: Re: (ngtrans) An IPv4 anycast address for 6to4<->6bone gateways In-reply-to: Your message of "Fri, 27 Oct 2000 15:46:25 MDT." <200010272146.PAA17119@hunkular.glarp.com> X-SUBJECT-MSG-FROM: Brad Huntting Date: Sat, 28 Oct 2000 04:25:39 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > One simple solution to this would seem to be to use a well known > IPv4 "anycast" address (call it "a.b.c.d" for now) for all 6to4 > gateways. I've thought about this a bit, and would like it slightly better if the v4 anycast address were used as the link layer address for a variant of router discovery (rather than assuming a default route to the anycast address). It's more versatile that way. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Oct 28 03:32:17 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) id e9SAUu320438 for ipng-dist; Sat, 28 Oct 2000 03:30:56 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e9SAUl320431 for ; Sat, 28 Oct 2000 03:30:47 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id DAA19370 for ; Sat, 28 Oct 2000 03:30:46 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA19253 for ; Sat, 28 Oct 2000 04:30:44 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e9SATIY54362; Sat, 28 Oct 2000 12:29:19 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id MAA23860; Sat, 28 Oct 2000 12:29:18 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id MAA26472; Sat, 28 Oct 2000 12:29:45 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200010281029.MAA26472@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Niveda Monyvannan" cc: members@ipv6forum.com, users@ipv6.org, ipng@sunroof.eng.sun.com Subject: Re: Subnet anycast address In-reply-to: Your message of Mon, 23 Oct 2000 17:53:22 +0530. Date: Sat, 28 Oct 2000 12:29:45 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: IPv6 specs says that 'IPv6 router should take receive the packet destined to Subnet anycast address and the Subnet anycast address is nothing but the subnet prefix + interface ID as 0' When a packet with Destination address as ' Subnet anycast address' is generated? => when someone wants to send a packet to any router (anycast works only for routers) in the subnet. I know no real usage of this as a final destination but this can be used in source routing if you'd like to go through a subnet, ie. this is a cheap & nice way to implement some kind of policy routing... How a source of the packet in a subnet ensures that the packet is delivered to only one person in the subnet? => first the source doesn't need to be in the subnet (only the knowledge of the subnet is needed). The packet is delivered to only one router in the subnet by definition of what is anycast. This is realized by one of these two cases: - if the packet comes from the exterior then the entry router can get the packet for him (it should be one of the routers in the anycast group) - if the packet is on the link of the subnet then the neighbor discovery (neighbor advertisements for an anycast address) will select one of the routers in the anycast group. This works for other anycast addresses (mobility home agent for instance) but in general the first case is less common for others. Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Oct 28 06:59:42 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) id e9SDvdo20521 for ipng-dist; Sat, 28 Oct 2000 06:57:39 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e9SDvS320513; Sat, 28 Oct 2000 06:57:29 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA01130; Sat, 28 Oct 2000 06:57:28 -0700 (PDT) Received: from aurora.cs.ucla.edu (Aurora.CS.UCLA.EDU [131.179.96.157]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA05188; Sat, 28 Oct 2000 06:57:15 -0700 (PDT) Received: (from lixia@localhost) by aurora.cs.ucla.edu (8.9.3+Sun/UCLACS-5.0) id GAA20174; Sat, 28 Oct 2000 06:55:46 -0700 (PDT) From: Lixia Zhang Message-Id: <200010281355.GAA20174@aurora.cs.ucla.edu> Subject: Re: 6over4 for KAME (FreeBSD) In-Reply-To: from Brian Zill at "Oct 27, 2000 02:40:23 pm" To: Brian Zill Date: Sat, 28 Oct 2000 06:55:45 -0700 (PDT) CC: "'f.johan.beisser'" , Brad Huntting , snap-users@kame.net, freebsd-questions@freebsd.org, ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, yjin@CS.UCLA.EDU X-Mailer: ELM [version 2.4ME+ PL60 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > 6to4 and 6over4, while having unfortunately similar names, are quite > different things. > > 6to4 is a form of automatic IPv6 tunneling over IPv4. The IPv4 address of > the "home" end of the tunnel is encoded into the IPv6 prefix. See > draft-ietf-ngtrans-6to4-07.txt. > > 6over4 is another IPv6 over "foo", where "foo" in this case is a > multicast-enabled IPv4 network, instead of say Ethernet or FDDI. See RFC > 2529. > > My recollection is that an implementation of 6over4 for some BSD flavor > exists, since I recall someone performing some interoperability testing > between our implementation and that implementation. UCLA sounds > familiar. yes we did an implementation a few years back, I also recall the interoperability test. Someone from 3com picked up our code? Yixin, can you recall more details? Lixia > Aren't two interoperating implementations a requirement for Proposed > Standard? (RFC 2529 is at PS) I'm not aware of any others offhand, but it > wouldn't surprise me if there were some. > > --Brian > > > -----Original Message----- > > From: f.johan.beisser [mailto:jan@caustic.org] > > Sent: Friday, 27 October, 2000 12:32 > > To: Brad Huntting > > Cc: snap-users@kame.net; freebsd-questions@FreeBSD.ORG; > > ngtrans@sunroof.eng.sun.com; ipng@sunroof.eng.sun.com > > Subject: Re: 6over4 for KAME (FreeBSD) > > > > > > > > i'm not sure if this is what you mean, but: > > > > http://www.kfu.com/~nsayer/6to4/ > > > > also, i think that it is documented on http://www.kame.net. > > > > of course, i oculd very well be talking out of my butt. > > > > -- jan > > > > > > > > On Fri, 27 Oct 2000, Brad Huntting wrote: > > > > > > > > Has anyone started writing a 6over4 (rfc2529) driver for KAME and/or > > > FreeBSD? > > > > > > I have a pointer to a UCLA project called "Virtual Ethernet" by > > > Quang Nguyen (no email address given), but it was written for the > > > Inria stack and FreeBSD2. If there's nothing else available, I > > > may use this as a guide. > > > > > > > > > -------/ f. johan beisser /--------------------------------------+ > > http://caustic.org/~jan jan@caustic.org > > "Never laugh at someone until you've walked a mile in their > > shoes. Then laugh. For you are a mile away, and > > you have their shoes." > > > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Oct 28 09:11:04 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) id e9SG9kg20565 for ipng-dist; Sat, 28 Oct 2000 09:09:46 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e9SG9b320558; Sat, 28 Oct 2000 09:09:37 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA21488; Sat, 28 Oct 2000 09:09:38 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA00011; Sat, 28 Oct 2000 10:09:36 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e9SG8lY34786; Sat, 28 Oct 2000 18:08:48 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id SAA01909; Sat, 28 Oct 2000 18:08:47 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id SAA29477; Sat, 28 Oct 2000 18:09:15 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200010281609.SAA29477@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: snap-users@kame.net cc: freebsd-questions@FreeBSD.ORG, ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: (KAME-snap 3558) 6over4 for KAME (FreeBSD) In-reply-to: Your message of Fri, 27 Oct 2000 13:21:37 MDT. <200010271921.NAA09586@hunkular.glarp.com> Date: Sat, 28 Oct 2000 18:09:15 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Has anyone started writing a 6over4 (rfc2529) driver for KAME and/or FreeBSD? => I have one and I know there is (was?) one done by the CAIRN group (perhaps the one you have referenced). I have a pointer to a UCLA project called "Virtual Ethernet" by Quang Nguyen (no email address given), but it was written for the Inria stack and FreeBSD2. If there's nothing else available, I may use this as a guide. => of course mine is for the INRIA stack but it is rather easy to adapt or rewrite... The only issue is you can't delete multicast structures because of the chaining but this is not an important issue (because of the lack of interest for 6over4?). Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Oct 28 09:25:24 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) id e9SGO8X20607 for ipng-dist; Sat, 28 Oct 2000 09:24:08 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e9SGNw320600; Sat, 28 Oct 2000 09:23:58 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA06240; Sat, 28 Oct 2000 09:23:58 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA03201; Sat, 28 Oct 2000 10:23:56 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e9SGMPY28939; Sat, 28 Oct 2000 18:22:25 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id SAA02250; Sat, 28 Oct 2000 18:22:24 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id SAA29597; Sat, 28 Oct 2000 18:22:50 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200010281622.SAA29597@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Brian Zill cc: "'f.johan.beisser'" , Brad Huntting , snap-users@kame.net, freebsd-questions@FreeBSD.ORG, ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: 6over4 for KAME (FreeBSD) In-reply-to: Your message of Fri, 27 Oct 2000 14:40:23 PDT. Date: Sat, 28 Oct 2000 18:22:50 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: My recollection is that an implementation of 6over4 for some BSD flavor exists, since I recall someone performing some interoperability testing between our implementation and that implementation. => I did some interoperability testing at the interim meeting in Tokyo using a 3Com multicast router (for fun!). I can remember details, only it was very soon in the morning... UCLA sounds familiar. => I got one day the CAIRN code but when I tried to port it to FreeBSD 3.x I discovered I had only some parts then I kept only the name (virtual Ethernet -> vet) which is in fact the (first/only) thing needed to implement a new flavor of IPv6 over IPv4 (I have 4 different ones :-). Aren't two interoperating implementations a requirement for Proposed Standard? (RFC 2529 is at PS) I'm not aware of any others offhand, but it wouldn't surprise me if there were some. => Cisco supported this but this was removed... Obviously 6to4 (a *different* thing) is far more popular (for bad reasons IMHO). Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Oct 28 12:02:16 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) id e9SJ10420670 for ipng-dist; Sat, 28 Oct 2000 12:01:00 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e9SJ0m320663; Sat, 28 Oct 2000 12:00:48 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA18151; Sat, 28 Oct 2000 12:00:47 -0700 (PDT) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA15357; Sat, 28 Oct 2000 13:00:46 -0600 (MDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id PAA02393; Sat, 28 Oct 2000 15:00:22 -0400 (EDT) Message-Id: <200010281900.PAA02393@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Francis Dupont cc: Brian Zill , "'f.johan.beisser'" , Brad Huntting , snap-users@kame.net, freebsd-questions@FreeBSD.ORG, ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: (ngtrans) Re: 6over4 for KAME (FreeBSD) In-reply-to: Your message of "Sat, 28 Oct 2000 18:22:50 +0200." <200010281622.SAA29597@givry.rennes.enst-bretagne.fr> Date: Sat, 28 Oct 2000 15:00:22 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > => Cisco supported this but this was removed... Obviously 6to4 (a *different* > thing) is far more popular (for bad reasons IMHO). 6to4 and 6over4 solve different problems; there's very little overlap in their applicability. So if there is more interest in 6to4 than 6over4 it may be only a reflection that it is easier to upgrade a private intranet to support native IPv6 (thus bypassing 6over4) than to upgrade the public Internet to support native IPv6. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 30 08:47:38 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) id e9UGk6B21513 for ipng-dist; Mon, 30 Oct 2000 08:46:06 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e9UGju321506 for ; Mon, 30 Oct 2000 08:45:57 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA23814 for ; Mon, 30 Oct 2000 08:45:56 -0800 (PST) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA10870 for ; Mon, 30 Oct 2000 09:45:54 -0700 (MST) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id QAA07888; Mon, 30 Oct 2000 16:45:49 GMT Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id QAA24418; Mon, 30 Oct 2000 16:45:39 GMT Message-ID: <39FDA5A0.A79A5FB5@hursley.ibm.com> Date: Mon, 30 Oct 2000 10:45:20 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Brian Zill CC: "'f.johan.beisser'" , Brad Huntting , snap-users@kame.net, freebsd-questions@FreeBSD.ORG, ipng@sunroof.eng.sun.com Subject: Re: 6over4 for KAME (FreeBSD) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, Thnaks for clarifying that. I'm working on a whole family of specs (6on4, 6under4, 6from4, 6and4...) to confuse everybody even more :-) No, Proposed Standard doesn't require interoperability - that's when you go to Draft Standard. Yes, there were a couple of implementations of 6over4 around, but I haven't yet thought about doing the due diligence to see if we are ready for Draft Standard. There is at least one pending change to the 6over4 spec that we agreed on a year ago (a SHOULD NOT instead of a MUST NOT). 6over4 is an IPNGWG item. I have deleted NGTRANS from the copies. Brian Carpenter Brian Zill wrote: > > 6to4 and 6over4, while having unfortunately similar names, are quite > different things. > > 6to4 is a form of automatic IPv6 tunneling over IPv4. The IPv4 address of > the "home" end of the tunnel is encoded into the IPv6 prefix. See > draft-ietf-ngtrans-6to4-07.txt. > > 6over4 is another IPv6 over "foo", where "foo" in this case is a > multicast-enabled IPv4 network, instead of say Ethernet or FDDI. See RFC > 2529. > > My recollection is that an implementation of 6over4 for some BSD flavor > exists, since I recall someone performing some interoperability testing > between our implementation and that implementation. UCLA sounds familiar. > Aren't two interoperating implementations a requirement for Proposed > Standard? (RFC 2529 is at PS) I'm not aware of any others offhand, but it > wouldn't surprise me if there were some. > > --Brian > > > -----Original Message----- > > From: f.johan.beisser [mailto:jan@caustic.org] > > Sent: Friday, 27 October, 2000 12:32 > > To: Brad Huntting > > Cc: snap-users@kame.net; freebsd-questions@FreeBSD.ORG; > > ngtrans@sunroof.eng.sun.com; ipng@sunroof.eng.sun.com > > Subject: Re: 6over4 for KAME (FreeBSD) > > > > > > > > i'm not sure if this is what you mean, but: > > > > http://www.kfu.com/~nsayer/6to4/ > > > > also, i think that it is documented on http://www.kame.net. > > > > of course, i oculd very well be talking out of my butt. > > > > -- jan > > > > > > > > On Fri, 27 Oct 2000, Brad Huntting wrote: > > > > > > > > Has anyone started writing a 6over4 (rfc2529) driver for KAME and/or > > > FreeBSD? > > > > > > I have a pointer to a UCLA project called "Virtual Ethernet" by > > > Quang Nguyen (no email address given), but it was written for the > > > Inria stack and FreeBSD2. If there's nothing else available, I > > > may use this as a guide. > > > > > > > > > -------/ f. johan beisser /--------------------------------------+ > > http://caustic.org/~jan jan@caustic.org > > "Never laugh at someone until you've walked a mile in their > > shoes. Then laugh. For you are a mile away, and > > you have their shoes." > > > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 30 10:59:08 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) id e9UIvC621799 for ipng-dist; Mon, 30 Oct 2000 10:57:12 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e9UIv7321792 for ; Mon, 30 Oct 2000 10:57:07 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id e9UIuNf24212 for ipng@sunroof.eng.sun.com; Mon, 30 Oct 2000 10:56:23 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e9U0W6321105 for ; Sun, 29 Oct 2000 16:32:06 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA07999 for ; Sun, 29 Oct 2000 16:32:06 -0800 (PST) Received: from newman.bestweb.net (newman.bestweb.net [209.94.100.171]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA00248 for ; Sun, 29 Oct 2000 16:32:06 -0800 (PST) Received: from bestweb.net (webmail.bestweb.net [209.94.100.130]) by newman.bestweb.net (Postfix) with SMTP id B37AF51635; Sun, 29 Oct 2000 19:32:05 -0500 (EST) From: "Guillaume Devianne" Reply-To: gdevianne@visiocomusa.com To: gdevianne@latinvalley.com Cc: ipng@sunroof.eng.sun.com Date: Sun, 29 Oct 2000 19:32:05 EDT Subject: Fwd: Protocol Action: IP Version 6 Management Information Base for the Multicast Listener Discovery Protocol to Proposed Standard X-Mailer: CWMail Web to Mail Gateway 2.4b, http://netwinsite.com/top_mail.htm Message-id: <39fcc185.b9a4.0@bestweb.net> X-User-Info: 200.27.133.112 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >To: IETF-Announce: ; From: The IESG >Date: Fri, 27 Oct 2000 12:55:22 -0400 > > > >The IESG has approved the Internet-Draft 'IP Version 6 Management >Information Base for the Multicast Listener Discovery Protocol' > as a Proposed Standard. This >document is the product of the IPNG Working Group. The IESG contact >persons are Erik Nordmark and Thomas Narten. > > > > >Technical Summary > >This document defines a portion of the Management Information Base >(MIB) for use with network management protocols in Internet Protocol >Version 6 internets. Specifically, this document is the MIB module >that defines managed objects for implementations of the Multicast >Listener Discovery Protocol (RFC2710). > >Working Group Summary > >There was consensus within the WG for this document, and no issues >were raised during IETF Last Call. > >Protocol Quality > >This protocol has been reviewed for the IESG by Juergen Schoenwaelder >and Thomas Narten. > > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 30 16:48:10 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id e9V0kZG22232 for ipng-dist; Mon, 30 Oct 2000 16:46:35 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id e9V0kVj22225 for ; Mon, 30 Oct 2000 16:46:31 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id e9V0jlw25862 for ipng@sunroof.eng.sun.com; Mon, 30 Oct 2000 16:45:47 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id e9V0fvj22212 for ; Mon, 30 Oct 2000 16:41:58 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA22869 for ; Mon, 30 Oct 2000 16:41:58 -0800 (PST) Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA05600 for ; Mon, 30 Oct 2000 16:41:57 -0800 (PST) Received: from zsc4c000.corpwest.baynetworks.com (actually zsc4c000.us.nortel.com) by smtprch1.nortel.com; Mon, 30 Oct 2000 16:16:55 -0600 Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Mon, 30 Oct 2000 14:11:37 -0800 Message-ID: <8B888AAAAB0FD31189590008C791844301B3F843@zbl6c002.corpeast.baynetworks.com> From: "Revathi Unnava" To: "'ipng@sunroof.eng.sun.com'" Cc: "Hamayon Mujeeb" Subject: Path MTU implementation issue Date: Mon, 30 Oct 2000 14:11:35 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C042BE.5E0FB100" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C042BE.5E0FB100 Content-Type: text/plain; charset="iso-8859-1" In RFC1981, Path MTU Discovery for IPv6, page 4, it is mentioned that: A node MUST NOT reduce its estimate of the Path MTU below the IPv6 minimum link MTU. Note: A node may receive a Packet Too Big message reporting a next-hop MTU that is less than the IPv6 minimum link MTU. In that case, the node is not required to reduce the size of subsequent packets sent on the path to less than the IPv6 minimun link MTU, but rather must include a Fragment header in those packets [IPv6- SPEC]. If a node discovers a path MTU X, which is less than IPv6 minimum link MTU (1280), it is not stored (as per RFC) with the local representation of the path. Now, when the node sends a packet of the size Y (Y > X), it receives a TooBig ICMP error. But it does not store the MTU that comes with that ICMP error. So next time there is a packet for that destination, it will still send it with the size Y. How does this work ? At the time we are sending, we have the packet, but dont have the correct MTU, while at the time of receiving TooBig error, we have the correct MTU, but dont have the packet to apply it to. Somebody please explain ... By the way, what is the purpose of having that restriction (dont store the PMTU < 1280) in the RFC ? I'll appreciate any help. Thanks Revathi ------_=_NextPart_001_01C042BE.5E0FB100 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Path MTU implementation issue

In RFC1981, Path MTU Discovery for = IPv6, page 4, it is mentioned that:

A node MUST NOT reduce its estimate of = the Path MTU below the IPv6 minimum link MTU.
Note: A node may receive a Packet Too = Big message reporting a next-hop MTU that is less than the IPv6 minimum = link MTU. In that case, the node is not required to reduce the size of = subsequent packets sent on the path to less than the IPv6 minimun link = MTU, but rather must include a Fragment header in those packets [IPv6- = SPEC].

If a node discovers a path MTU X, = which is less than IPv6 minimum link MTU (1280),
it is not stored (as per RFC) with = the local representation of the path. Now, when the node sends a = packet
of the size Y (Y > X), it receives = a TooBig ICMP error. But it does not store the MTU that comes = with
that ICMP error. So next time there = is a packet for that destination, it will still send it with the size = Y.
How does this work ? At the time we = are sending, we have the packet, but dont have the correct MTU,
while at the time of receiving TooBig = error, we have the correct MTU, but dont have the packet to
apply it to. Somebody please explain = ...

By the way, what is the purpose of = having that restriction (dont store the PMTU < 1280)  in the = RFC ?

I'll appreciate any help.

Thanks
Revathi

------_=_NextPart_001_01C042BE.5E0FB100-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Oct 30 16:56:55 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id e9V0tn222250 for ipng-dist; Mon, 30 Oct 2000 16:55:49 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id e9V0tcj22243 for ; Mon, 30 Oct 2000 16:55:39 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA16662 for ; Mon, 30 Oct 2000 16:55:39 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA19186 for ; Mon, 30 Oct 2000 16:55:37 -0800 (PST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id JAA21119; Tue, 31 Oct 2000 09:55:26 +0900 (JST) To: "Revathi Unnava" cc: "'ipng@sunroof.eng.sun.com'" , "Hamayon Mujeeb" In-reply-to: runnava's message of Mon, 30 Oct 2000 14:11:35 PST. <8B888AAAAB0FD31189590008C791844301B3F843@zbl6c002.corpeast.baynetworks.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Path MTU implementation issue From: itojun@iijlab.net Date: Tue, 31 Oct 2000 09:55:26 +0900 Message-ID: <21117.972953726@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >In RFC1981, Path MTU Discovery for IPv6, page 4, it is mentioned that: > >A node MUST NOT reduce its estimate of the Path MTU below the IPv6 minimum >link MTU. >Note: A node may receive a Packet Too Big message reporting a next-hop MTU >that is less than the IPv6 minimum link MTU. In that case, the node is not >required to reduce the size of subsequent packets sent on the path to less >than the IPv6 minimun link MTU, but rather must include a Fragment header in >those packets [IPv6- SPEC]. see RFC2460 section 5, very beginning. itojun --- 5. Packet Size Issues IPv6 requires that every link in the internet have an MTU of 1280 octets or greater. On any link that cannot convey a 1280-octet packet in one piece, link-specific fragmentation and reassembly must be provided at a layer below IPv6. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 31 07:41:42 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id e9VFdni22732 for ipng-dist; Tue, 31 Oct 2000 07:39:49 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id e9VFdcj22725 for ; Tue, 31 Oct 2000 07:39:38 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA25014 for ; Tue, 31 Oct 2000 07:39:38 -0800 (PST) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA01950 for ; Tue, 31 Oct 2000 07:39:37 -0800 (PST) Received: by zmamail04.zma.compaq.com (Postfix, from userid 12345) id 74A555F7; Tue, 31 Oct 2000 10:39:37 -0500 (EST) Received: from exctay-gh03.tay.cpqcorp.net (exctay-gh03.tay.cpqcorp.net [16.103.129.53]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 630555D9 for ; Tue, 31 Oct 2000 10:39:37 -0500 (EST) Received: by exctay-gh03.tay.cpqcorp.net with Internet Mail Service (5.5.2650.21) id ; Tue, 31 Oct 2000 10:39:21 -0500 Message-ID: From: "Powell, Ken" To: "'John F. Leser'" Cc: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM, ipng@sunroof.eng.sun.com Subject: RE: [MOBILE-IP] MIPv6 node location detection Date: Tue, 31 Oct 2000 10:39:09 -0500 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Sorry for the delay, still catching up on this thread. > -----Original Message----- > From: John F. Leser [mailto:jfl@iol.unh.edu] > Sent: Wednesday, October 18, 2000 11:11 AM > To: Thomas Eklund > Cc: Francis Dupont; MOBILE-IP@STANDARDS.NORTELNETWORKS.COM; > ipng@sunroof.eng.sun.com > Subject: Re: [MOBILE-IP] MIPv6 node location detection > - Require that a home agent's router advertisements always contain all > of the prefixes on the network that are valid for home or CO > addresses. I like the idea and think it makes sense for stateless address autoconfiguration, but how would it work with other address configuration methods like DHCPv6? Does this put restrictions on where DHCPv6 could be used? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 31 10:03:49 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id e9VI2C122868 for ipng-dist; Tue, 31 Oct 2000 10:02:12 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id e9VI1uj22861; Tue, 31 Oct 2000 10:01:56 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA12474; Tue, 31 Oct 2000 10:01:54 -0800 (PST) Received: from seattle.3com.com (seattle.3com.com [129.213.128.97]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA19866; Tue, 31 Oct 2000 10:01:53 -0800 (PST) Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by seattle.3com.com (8.8.8/8.8.8) with ESMTP id JAA15608; Tue, 31 Oct 2000 09:59:53 -0800 (PST) Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.8/8.8.8) with ESMTP id JAA05038; Tue, 31 Oct 2000 09:59:53 -0800 (PST) Received: from cyndi (vpn-243.nsd.3com.com [129.213.205.243]) by chicago.nsd.3com.com (8.8.8/8.8.8) with SMTP id JAA17414; Tue, 31 Oct 2000 09:59:43 -0800 (PST) Message-Id: <3.0.6.32.20001031095834.01960af0@mailhost.ewd.3com.com> X-Sender: cmj@mailhost.ewd.3com.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Tue, 31 Oct 2000 09:58:34 -0800 To: Lixia Zhang , Brian Zill From: Cyndi Jung Subject: Re: (ngtrans) Re: 6over4 for KAME (FreeBSD) Cc: "'f.johan.beisser'" , Brad Huntting , snap-users@kame.net, freebsd-questions@freebsd.org, ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, yjin@CS.UCLA.EDU In-Reply-To: <200010281355.GAA20174@aurora.cs.ucla.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk We did some interoperability testing between the UCLA code and the Microsoft code, but we never picked up the code, and in fact had toruble putting the UCLA software together until Yixin somehow put a kernel together that would work for our test. It was a proof of concept, but it didn't go beyond that. The UCLA code was built on the Francis' stack from Inria, and I don't know how different that is from the KAME stack. Francis had the 6over4 from UCLA in his code when we went to Tokyo last year for the interim IPng meeting and TAHI interoperability test - I helped him do a little interoperability test there with Richard Draves from Microsoft, by giving them a multi-hop IPv4 network with multicast service - it was no surprise to any of us that it worked, but it was nice to see. So, Francis - you are the last person seen (by me) with a working 6over4 on freeBSD! Cyndi At 06:55 AM 10/28/00 -0700, Lixia Zhang wrote: >> 6to4 and 6over4, while having unfortunately similar names, are quite >> different things. >> >> 6to4 is a form of automatic IPv6 tunneling over IPv4. The IPv4 address of >> the "home" end of the tunnel is encoded into the IPv6 prefix. See >> draft-ietf-ngtrans-6to4-07.txt. >> >> 6over4 is another IPv6 over "foo", where "foo" in this case is a >> multicast-enabled IPv4 network, instead of say Ethernet or FDDI. See RFC >> 2529. >> >> My recollection is that an implementation of 6over4 for some BSD flavor >> exists, since I recall someone performing some interoperability testing >> between our implementation and that implementation. UCLA sounds >> familiar. > >yes we did an implementation a few years back, I also recall the >interoperability test. >Someone from 3com picked up our code? >Yixin, can you recall more details? > >Lixia > > > >> Aren't two interoperating implementations a requirement for Proposed >> Standard? (RFC 2529 is at PS) I'm not aware of any others offhand, but it >> wouldn't surprise me if there were some. >> >> --Brian >> >> > -----Original Message----- >> > From: f.johan.beisser [mailto:jan@caustic.org] >> > Sent: Friday, 27 October, 2000 12:32 >> > To: Brad Huntting >> > Cc: snap-users@kame.net; freebsd-questions@FreeBSD.ORG; >> > ngtrans@sunroof.eng.sun.com; ipng@sunroof.eng.sun.com >> > Subject: Re: 6over4 for KAME (FreeBSD) >> > >> > >> > >> > i'm not sure if this is what you mean, but: >> > >> > http://www.kfu.com/~nsayer/6to4/ >> > >> > also, i think that it is documented on http://www.kame.net. >> > >> > of course, i oculd very well be talking out of my butt. >> > >> > -- jan >> > >> > >> > >> > On Fri, 27 Oct 2000, Brad Huntting wrote: >> > >> > > >> > > Has anyone started writing a 6over4 (rfc2529) driver for KAME and/or >> > > FreeBSD? >> > > >> > > I have a pointer to a UCLA project called "Virtual Ethernet" by >> > > Quang Nguyen (no email address given), but it was written for the >> > > Inria stack and FreeBSD2. If there's nothing else available, I >> > > may use this as a guide. >> > > >> > >> > >> > -------/ f. johan beisser /--------------------------------------+ >> > http://caustic.org/~jan jan@caustic.org >> > "Never laugh at someone until you've walked a mile in their >> > shoes. Then laugh. For you are a mile away, and >> > you have their shoes." >> > >> > >> > -------------------------------------------------------------------- >> > IETF IPng Working Group Mailing List >> > IPng Home Page: http://playground.sun.com/ipng >> > FTP archive: ftp://playground.sun.com/pub/ipng >> > Direct all administrative requests to majordomo@sunroof.eng.sun.com >> > -------------------------------------------------------------------- >> > >> -------------------------------------------------------------------- >> IETF IPng Working Group Mailing List >> IPng Home Page: http://playground.sun.com/ipng >> FTP archive: ftp://playground.sun.com/pub/ipng >> Direct all administrative requests to majordomo@sunroof.eng.sun.com >> -------------------------------------------------------------------- > > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 31 10:09:19 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id e9VI7mg22905 for ipng-dist; Tue, 31 Oct 2000 10:07:48 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id e9VI7hj22898 for ; Tue, 31 Oct 2000 10:07:44 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id e9VI6wH26025 for ipng@sunroof.eng.sun.com; Tue, 31 Oct 2000 10:06:58 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id e9V6prj22522 for ; Mon, 30 Oct 2000 22:51:54 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id WAA01879 for ; Mon, 30 Oct 2000 22:51:49 -0800 (PST) Received: from indiainfo.com ([203.199.69.94]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA13545 for ; Mon, 30 Oct 2000 22:51:42 -0800 (PST) Received: from [203.197.138.194] (account ) by indiainfo.com (CommuniGate Pro WebUser 3.4b1) with HTTP id 5495617; Tue, 31 Oct 2000 12:19:28 +0530 From: "Niveda Monyvannan" Subject: Clarification in RFC 2465 To: ipng@sunroof.eng.sun.com, 6bone@isi.edu, users@ipv6.org X-Mailer: CommuniGate Pro Web Mailer v.3.4b1 Date: Tue, 31 Oct 2000 12:19:28 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, ipv6AddrTable and ipv6AddrPrefixTable, described in RFC 2465 are read-only table. Where/how do we configure Anycast/Unicast addresses for a router? Similarly As ND is specific to IPV6, the configuration for Autonomous flag, Onlink Flag, Preferred Life time and Valid life time should be configurable using IPv6 mib, whereas all these variables are read-only in the standard mib. Even the RouteTable is not having an object of RowStatus type. Where do we add static routes? The emailID of authors specified in the RFC seems to be invalid as i get the bounced mails. Can anyone clarify this? Regards, Niveda ---------------------------------------- http://mail.indiainfo.com First you had 10MB of free mail space. Now you can send mails in your own language !!! -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Oct 31 10:29:07 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) id e9VIR9822956 for ipng-dist; Tue, 31 Oct 2000 10:27:09 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2.Beta0+Sun/8.11.2.Beta0) with ESMTP id e9VIQvj22949 for ; Tue, 31 Oct 2000 10:26:58 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA19566 for ; Tue, 31 Oct 2000 10:26:56 -0800 (PST) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA20505 for ; Tue, 31 Oct 2000 10:26:45 -0800 (PST) Received: by zmamail05.zma.compaq.com (Postfix, from userid 12345) id D40DA5832; Tue, 31 Oct 2000 13:26:41 -0500 (EST) Received: from exctay-gh01.tay.cpqcorp.net (exctay-gh01.tay.cpqcorp.net [16.103.129.42]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id C31BB3AF6 for ; Tue, 31 Oct 2000 13:26:41 -0500 (EST) Received: by exctay-gh01.tay.cpqcorp.net with Internet Mail Service (5.5.2650.21) id ; Tue, 31 Oct 2000 13:26:41 -0500 Message-ID: From: "Powell, Ken" To: "'John F. Leser'" , "'MOBILE-IP@STANDARDS.NORTELNETWORKS.COM'" , "'ipng@sunroof.eng.sun.com'" , "'Charles E. Perkins'" Subject: RE: [MOBILE-IP] MIPv6 node location detection Date: Tue, 31 Oct 2000 13:26:38 -0500 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Following upon a comment I made yesterday about John Leser's proposal... > > - Require that a home agent's router advertisements always > > contain all of the prefixes on the network that are valid > > for home or CO addresses. > Would it make sense to state configuration limitations as > a fact; then, mandate that home agents MUST (SHOULD?) check > for inconsistencies in received router advertisements and > report any errors? I was thinking that in addition to the consistency checks required by RFC 2461 section 6.2.7, the following specific checks SHOULD be made on a home agent when it receives a Router Advertisement on the home subnet: 1) If the M or O flag is set in the received Router Advertisement, verify the corresponding bit is set in the home agents own router advertisements. 2) Verify all prefixes received in the Prefix Information option are included in the home agent's own AdvPrefixList. 3) If the value of the L or A flag of a received prefix is set, verify the corresponding flag in the home agent's AdvPrefixList is also set. The R flag in received Prefix Information option should be ignored by the home agent. Any inconsistencies SHOULD be logged to system or network management. Ken -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com --------------------------------------------------------------------