The draft should not be considered for 6man as a WG item just yet because it needs some more work before the draft is even acceptable to review. Here is some things to look at after I read portions of the draft at the URL below.
1. Section 1 of the draft says 2001:db8:3001:1:EN is selected as the source address of a packet directed from CN to EN. Huh? CN has only an address of 2001:db8:2001::CN, so how can a src of 2001:db8:3001:1:EN be picked? 2. Section 1 says: [Here, in the above IPv6 address notation, CN, R1, R2, and EN indicates 64bit Interface ID's.] There is no router R2 in the picture of Fig. 1. How can one review this document with such basic mistakes/typos in the picture? 3. In section 3 you say: [Before Rule 8 (Use longest matching prefix) in section 5. (Source Address Selection) in RFC3484, the rule using longest-matching prefix to the next hop is to be added.] Did I get is right that you are changing src-addr based on next hop? Basic IP data forwarding and routing ships packets between consecutive hops using L2 addresses. For packet flow from src to dest with multiple hops in between, the L3 src and dest addresses do not change! Src and dest L3 addresses can only be changed by some proxy node in the path. I hope you are not suggesting changing L3 src-addr from hop to hop! I suggest you forget about the solution. First define your src-addr selection problem and let the mailer first agree you have a problem. Then we'll see what is the solution. You have a lot of sections in the draft with problems/issues, viz., 1. A Problem of at Source Address Selection Rule 8. in RFC3484 2.1 Management Issue 2.2 Implementation Issue It confuses the reader as to what is the one single problem you are trying to solve. Or if you are solving multiple problems, list them at the beginning of the draft. Sorry, if I have missed such problem definitions in the mailer earlier than one year from now. I suggest the same to the authors of draft-ietf-6man-addr-select-sol-00.txt. Could you please first describe what is the problem with SAS as specified in RFC 3484. Hemant -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of FUJIKAWA Kenji Sent: Monday, February 25, 2008 9:31 PM To: [email protected] Subject: Use longest-matching prefix to the next hop Hi all, I am submitting an ID, http://www.ietf.org/proceedings/staging/draft-fujikawa-ipv6-src-addr-sel ection-02.txt and suggesting in the draft that, Before Rule 8 (Use longest matching prefix) in section 5. (Source Address Selection) in RFC3484, the rule using longest-matching prefix to the next hop is to be added. The following is an example, where the Rule 8 selects the roundabout path via ISP3, while the method of using longest-matching prefix to the next hop selects the shortest and best path, when EN sends a packet to CN. # In the previous IETF meeting I only showed a single router case. # but this method is adaptable and useful to the multiple router case. I would like to ask if 6man people is interested in this topic, and this can become working group item. +---+ |CN | +-+-+ | 2001:db8:2001::CN | +---+---+2001:db8:2000:/36 | | +---------+ ISP2 | | | | | +-------+ | +---+---+2001:db8:1000:/36 +-------+2001:db8:3000::/36 | | | | | ISP1 +-------------------+ ISP3 | | | | | +---+---+ +---+---+ | | | | +----------+ +--------+ 2001:db8:1000:R1| |2001:db8:3000:R3 +-+-+ +-+-+ 2001:db8:1001::/48|R1 | |R3 |2001:db8:3001::/48 +-+-+ +-+-+ 2001:db8:1001:1:R1| |2001:db8:3001:1:R3 | | --+---+---+-- 2001:db8:1001:1:EN | 2001:db8:3001:1:EN +-+-+ |EN | +---+ Routing Tables: R1: Destination Next Hop 2001:db8:1000::/36 address_of_ISP1's_router 2001:db8:2000::/36 address_of_ISP1's_router R3: 2001:db8:3000::/36 address_of_ISP3's_router EN: Destination Next Hop 2001:db8:1000::/36 2001:db8:1001:1:R1 2001:db8:2000::/36 2001:db8:1001:1:R1 2001:db8:3000::/36 2001:db8:3001:1:R3 Any questions and comments are welcome. Regards, ------------------------------------------------------------------ FUJIKAWA Kenji(Ph. D.) ROOT Inc., Osaka Information Laboratory 5F Pias Tower, 3-19-3 Toyosaki Kita-ku, Osaka, 531-0072, Japan Mail: [EMAIL PROTECTED], [EMAIL PROTECTED] WWW: http://www23.atwiki.jp/hudikaha/ Skype: fujikawakenji -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
