FYI.
Regards,
Thomas Trede
----- Original Message -----
From: "Dave Johnson" <dbj(a)cs.cmu.edu>
To: <mobile-ip(a)standards.nortelnetworks.com>; <ipng(a)sunroof.eng.sun.com>
Sent: Thursday, April 27, 2000 8:57 PM
Subject: New version of "Mobility Support in IPv6" draft
> I just submitted a revised version of the Internet-Draft "Mobility
> Support in IPv6", which corrects a number of minor problems and adds
> several clarifications over the previous version of the draft. Here
> is a list of some of the changes since the previous version:
>
> - Moved the definition of IPsec requirements for Binding Updates
> and Binding Acknowledgements to Section 4.4), giving this
> important information its own specific section with a section
> title (IPsec Requirements for Mobile IPv6 Destination Options)
> that will be identifiable in the table of contents for this
> document. This makes these requirements harder to miss than
> where they were defined in Sections 5.1 and 5.2, mixed in with
> the definition of the format of these destination options.
>
> - In Section 4.6, added a precise definition of Sequence Number
> value comparison modulo 2**16. Also added a reference to this
> definition in each other place where Sequence Number comparison
> is discussed.
>
> - Added a statement in Section 9.5 to clarify the sending of a
> Neighbor Advertisement message by the home agent on behalf of the
> mobile node in order to intercept packets addressed to the mobile
> node. Except for the specific fields defined there, all fields
> in each such Neighbor Advertisement SHOULD be set in the same
> way they would be set by the mobile node itself if sending this
> Neighbor Advertisement while at home [17].
>
> - In Section 10.6, specified that the Lifetime in the Binding
> Update sent by a mobile node to its home agent SHOULD be less
> than or equal to the remaining lifetime of the home address and
> the care-of address specified for the binding.
>
> - In Section 10.8, modified the specification that was there
> about the correct setting of the Lifetime in the Binding
> Update sent by a mobile node to a correspondent node. The
> original specification stated that the Lifetime value MUST be no
> greater than the remaining lifetime of the mobile node's home
> registration of its primary care-of address at its home agent.
> However, there should be no necessary relationship between the
> remaining lifetime of a home registration and the lifetime of
> a binding at a correspondent node. Instead, as with the home
> registration Binding Update, the Lifetime in the Binding Update
> sent by a mobile node to a correspondent node SHOULD be less than
> or equal to the remaining lifetime of the home address and the
> care-of address specified for the binding.
>
> - In Section 5.4, added a statement that a packet MUST NOT contain
> more than one Home Address option, except that an encapsulated
> packet [4] MAY contain a separate Home Address option associated
> with each encapsulating IP header.
>
> - In Section 4.6, added a new field in the Binding Update List
> entry format to record the initial value of the Lifetime field
> sent in that Binding Update.
>
> - In Section 10.12, defined a new step in processing a received
> Binding Acknowledgement: if the value specified in the Lifetime
> field in the Binding Acknowledgement is less than the Lifetime
> value sent in the Binding Update being acknowledged, then the
> mobile node MUST subtract the difference between these two
> Lifetime values from the remaining lifetime for the binding
> as maintained in the corresponding Binding Update List entry.
> The effect of this step is to correctly manage the mobile
> node's view of the binding's remaining lifetime (as maintained
> in the corresponding Binding Update List entry) so that it
> correctly counts down from the Lifetime value given in the
> Binding Acknowledgement, but with the timer countdown beginning
> at the time that the Binding Update was sent. This change also
> affected Section 10.8 in sending Binding Updates, to record both
> the original lifetime and the remaining lifetime in the Binding
> Update List.
>
> - In Sections 5.1 and 9.3, clarified that the Duplicate Address
> Detection performed by the home agent if the Duplicate Address
> Detection (D) bit is set in the Binding Update, is performed
> before returning the Binding Acknowledgement for that Binding
> Update.
>
> - In Section 5.1, clarified that the mobile node SHOULD set the
> Duplicate Address Detection (D) bit in its home registration
> Binding Updates based on any requirements for Duplicate Address
> Detection that would apply to the mobile node if it were at
> home [17, 27].
>
> - In Section 9.3, specified that a home agent, when performing
> Duplicate Address Detection for a mobile node when the
> Duplicate Address Detection (D) bit is set in a received
> Binding Update, SHOULD NOT delay sending the initial Neighbor
> Solicitation message of Duplicate Address Detection by the random
> delay specified for normal processing of Duplicate Address
> Detection [17, 27].
>
> - In Section 10.5, defined special considerations for a mobile
> node's use of Duplicate Address Detection upon forming a new
> care-of address. In particular, the mobile node MAY begin
> using the new care-of address without performing Duplicate
> Address Detection, and MAY optionally bypass Duplicate Address
> Detection or begin Duplicate Address Detection asynchronously
> when it begins use of the address, allowing the Duplicate
> Address Detection procedure to complete in parallel with
> normal communication using the address. In addition, the
> mobile node SHOULD NOT delay sending the initial Neighbor
> Solicitation message of Duplicate Address Detection by the random
> delay specified for normal processing of Duplicate Address
> Detection [17, 27], unless the mobile node is initializing after
> rebooting.
>
> - In Section 4.6, added a clarification to the definition of the
> Binding Update List, that for multiple Binding Updates sent to
> the same destination address, the Binding Update List contains
> only the most recent Binding Update (i.e., with the greatest
> Sequence Number value) sent to that destination. This was
> already noted in previous versions of the draft in the sending of
> Binding Updates, as defined in Section update-corresp, but was
> not previously stated explicitly in the definition of the Binding
> Update List conceptual data structure.
>
> - In Section 9.3, added a specification that the lifetime for the
> Binding Cache entry (and thus the Lifetime value returned in the
> Binding Acknowledgement) MUST NOT be greater than the Lifetime
> value specified in the Binding Update. Also added a similar
> specification (and clarification) in Section 8.3 for the Binding
> Cache entry in a correspondent node.
>
> - In Section 10.6, added a clarification that, when sending a
> Binding Update to its home agent, the mobile node MUST also
> create or update the corresponding Binding Update List entry, as
> specified in Section 10.8.
>
> The official announcement of the draft should appear on the mailing
> lists shortly, but you can get a copy of the new draft now from
>
>
http://www.monarch.cs.cmu.edu/internet-drafts/draft-ietf-mobileip-ipv6-12.tx
t
>
> We expect to go to Last Call on this version of the draft shortly.
> Please send any comments on the draft to the Mobile IP mailing list at
> mobile-ip(a)standards.nortelnetworks.com.
>
> Thanks.
>
> Dave
>
> --
> David B. Johnson dbj(a)cs.cmu.edu
> Associate Professor http://www.cs.cmu.edu/~dbj/
> Computer Science Department http://www.monarch.cs.cmu.edu/
> Carnegie Mellon University Phone: (412) 268-7399
> 5000 Forbes Avenue Fax: (412) 268-5576
> Pittsburgh, PA 15213-3891
>
> --------------------------------------------------------------------
> 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(a)sunroof.eng.sun.com
> --------------------------------------------------------------------
>
FYI.
Regards,
Thomas Trede
----- Original Message -----
From: "Ray LaRocca" <rglr(a)iol.unh.edu>
To: <ipng(a)sunroof.eng.sun.com>
Cc: "Ray LaRocca" <rglr(a)iol.unh.edu>
Sent: Monday, April 10, 2000 9:11 PM
Subject: UNH Cthon, Forum results
> Hello All,
>
> The following are the results of the UNH testing at Connectathon 2000 and
> the IPv6 Forum meeting in Telluride.
>
> Connectathon 2000:
> 1. 15 IPv6 implementations were present (5 times as many as last year)
> 2. We tested Mobile IPv6, RIPng and BGP4+ interoperability (as well as
> some conformance testing)
>
> IPv6 Forum, Telluride:
> 1. 7 IPv6 implementations were present
> 2 We tested RIPng, BGP4+, and tunneling interoperability (some conformance
> testing here also)
>
> ---------------------------------------------------------------
> Mobility testing at Connectathon:
> ---------------------------------------------------------------
> Participants:
> ENST Bretagne, Ericsson, Ericsson-Telebit, Microsoft Research, NEC, Nokia
>
> Implementations present:
> 5 home agents, 3 mobile nodes, 4 correspondent nodes
>
> Testing Highlights:
> Approximately 20 interoperability tests were run over the course of the 3
> days of testing. We had a moderate level of interoperability even though
> the implementations were in various stages of development (version 8, 9,
> and 10 of the spec were present). The participants spent much of the time
> debugging and modifying their code.
>
> Testing Topology:
> 4 networks connected via a single mobile unaware v6 router.
>
> Testing Scenarios:
> (A)
> 1. A home agent, mobile node pair begin on the home network with a
> correspondent node residing on a foreign network.
> 2. The mobile node moves from the home network to a foreign network while
> pinging the correspondent node.
> 3. The mobile node then moves from a foreign network to another foreign
> network continuing to ping the correspondent node.
> 4. The mobile node then moves to the foreign network where the
> correspondent node resides (still pinging)
> 5. The mobile node returns home.
>
> (B)
> The same as above except with a telnet session open between the mobile
> node and the correspondent node.
>
> We were able to achieve success in both of the above scenarios.
>
> Issues/Questions:
> 1. Versions 8, 9, and 10 of the spec were present.
> 2. There were issues involving DAD when the mobile node returned home
> (this has been addressed in version 11 of the spec)
> 3. Issues with option ordering in the packet have also been addressed in
> version 11 of the spec
> 4. There was an implementation incorrectly detecting movement by detecting
> the different EUI-64 of the router. In our setup the router was using the
> same EUI-64 for each of its interfaces thus causing difficulty for that
> implementation to detect movement. This issue was presented to Dave
> Johnson and he has addressed this issue to the mobileip working group.
>
> What Next?
> 1. We need to have an interoperability test event within 6 months to
> include Mobile IPv4, DIAMETER, and Mobile IPv6, with IPsec interaction.
(TBD)
> 2. UNH IOL has developed Mobile IPv6 conformance tests and is currently
> providing the testing service.
>
> ---------------------------------------------------------------
> Routing and conformance testing at both Connectathon and IPv6 Forum
> ---------------------------------------------------------------
> Participants: 3Com, Cisco, COMPAQ, Ericsson-Telebit, HP, Hitachi, KAME,
> Microsoft Research, NOKIA, Nortel, SCO, SGI, SUN
>
> RIPng:
> 1. 14 implementations with nearly 100% interoperability
> 2. Some minor issues that were implementation-specific
> 3. The basic setup was all routers on the same network with some
> configured routes being advertised.
> 4. 1 question regarding advertising a prefix for a network on the actual
> network was posted to the ipng mailing list. Implementations were doing
> one of 3 things: advertise the prefix with metric 1, metric 16, or not
> advertise it at all.
>
> BGP4+:
> 1. 9 implementations with nearly 100% interoperability
> 2. Some minor issues that were implementation-specific
> 3. The basic setup was all routers on the same network establishing both
> internal and external peer sessions with other routers.
>
>
> ---------------------------------------------------------------
>
>
>
>
>
>
>
>
> --------------------------------------------------------------------
> 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(a)sunroof.eng.sun.com
> --------------------------------------------------------------------
>
FYI.
Regards,
Thomas Trede
----- Original Message -----
From: <Internet-Drafts(a)ietf.org>
To: <IETF-Announce: ;>
Cc: <ipng(a)sunroof.eng.sun.com>
Sent: Monday, April 10, 2000 1:34 PM
Subject: I-D ACTION:draft-ietf-ipngwg-site-prefixes-04.txt
> 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 : Site prefixes in Neighbor Discovery
> Author(s) : E. Nordmark
> Filename : draft-ietf-ipngwg-site-prefixes-04.txt
> Pages : 22
> Date : 06-Apr-00
>
> This document specifies extensions to IPv6 Neighbor Discovery to
> carry site prefixes. The site prefixes are used to reduce the effect
> of site renumbering by ensuring that the communication inside a site
> uses site-local addresses.
> This protocol requires that all IPv6 implementations, even those that
> do not implement this protocol, ignore all site-local addresses that
> they retrieve from the DNS when the AAAA or A6 RRset contain both
> global and site-local addresses. If the RRset contains only site-
> local addresses those addresses can be used.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-site-prefixes-04.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-site-prefixes-04.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(a)ietf.org.
> In the body type:
> "FILE /internet-drafts/draft-ietf-ipngwg-site-prefixes-04.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.
>
