Fujikawa san, I leave it to the WG to decide what to do with this draft. What you are suggesting for a solution is already mentioned in RFC 3484. So I don't know understand why we need your draft? Maybe it can be an Information draft. I don't see a category of Standards Track or Informational in your draft.
What you are suggesting for solution is already motioned in RFC 3484. Here is that information. Section 5, Rule 8 says [Rule 8 may be superseded if the implementation has other means of choosing among source addresses. For example, if the implementation somehow knows which source address will result in the "best" communications performance.] "best" communication performance can mean best routing path. Further section 7 of the same RFC explains how does SAS interface with routing. Snipped below is a text that says [Implementations may also use the choice of router to influence the choice of source address. For example, suppose a host is on a link with two routers. One router is advertising a global prefix A and the other router is advertising global prefix B. Then when sending via the first router, the host may prefer source addresses with prefix A and when sending via the second router, prefer source addresses with prefix B.] The text above is your solution described in section 2.2 of your draft. You look up the routing entry for the destination first (like how section 7 of RFC 3484 also says), and then on seeing that the routing entry shows path thru router R1 (in your example), then EN will use the 2001:db8:1001:1:EN for src-addr (this is what the sentence in section 7 of RFC 3484 also says). Is your solution any different from what is already described in RFC 3284? What am I missing? Thanks. Hemant -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of FUJIKAWA Kenji Sent: Wednesday, February 27, 2008 11:34 PM To: ipv6@ietf.org Subject: Re: Use longest-matching prefix to the next hop Hemant Singh; Thank you for your comments. At Wed, 27 Feb 2008 16:01:27 -0500, Hemant Singh (shemant) wrote: > > 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? > Because 2001:db8:3001:1:EN longer-matches to 2001:db8:2001::CN than 2001:db8:1001:1:EN. # Note that 1 = 01, 2 = 10, and 3 = 11 in binary form. > 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. > This is typo. > 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! > No, I am 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 see. Thank you for your advice. 2.1 and 2.2 should be "Management Approach" and "Implementation Approach" or something. > 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 > ------------------------------------------------------------------ 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 > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of FUJIKAWA Kenji > Sent: Monday, February 25, 2008 9:31 PM > To: ipv6@ietf.org > 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-s > el > 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 > ipv6@ietf.org > Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
