Re: [Softwires] Comments on 4rd-u-04

[Rémi Després <[e-mail]>]

Le 2012-03-13 à 01:59, Maoke a écrit :

> hi Remi,
> 
> 2012/3/12 Rémi Després <[e-mail]>
> Maoke,
> 
> 1.
> What you call the cost of "IANA authority on the use of V-bit" is neither a development nor an operational cost. Once standardization is done, the cost becomes 0.
> 
> exactly. 
>  
> 
> 2.
> Isn't it true that MAP addresses must have the "u" octet, i.e. 0x00, in address bits 64-71?
> If yes, MAP example addresses you give with 0x02 or 0x03 instead of "u", aren't AFAIK valid MAP addresses.
> 
> oh, yes! i made the typo, falling into the EUI-64 case. MAP cites RFC6052 format for IID, while the latter states:
> "Bits 64 to 71 of the address are reserved for compatibility with the
> host identifier format defined in the IPv6 addressing architecture
>   [RFC4291]. These bits MUST be set to zero." 
> 
> thanks a lot for pointing out the mistake! the corresponding example should be corrected as:
> 
> #1. shared ipv4 address
> take an example of delegated prefix 2001:db8:1234:5678::/64 and the IPv4 address for the CE is 0xabcde567, PSID=8. 
> 
> MAP (without V-octet):
> native IPv6: 2001:db8:1234:5678::/64
> mapped IPv6: 2001:db8:1234:5678:00ab:cde5:6780:0000/128 (as a more-specific) 
> cost: almost none.
> 
> #2. exclusive ipv4 address
> 2001:db8:1234:5670::/60, IPv4 address 0xabcde567
> 
> MAP (without V-octet):
> native IPv6: 2001:db8:1234:5670::/60
> mapped IPv6: 2001:db8:1234:5670:00ab:cde5:6700:0000/128 (as a more-specific) 
> cost: almost none. 
> 
> #3. exclusive ipv4 subnet
> 2001:db8:1234:5600::/56, IPv4 address 0xabcde560~0xabcde56f
> 
> MAP (without V-octet):
> native IPv6: 2001:db8:1234:5600::/56
> mapped IPv6: 2001:db8:1234:5600:00ab:cde5:6000:0000/128 (as a more-specific)
>              2001:db8:1234:5610:00ab:cde5:6100:0000/128 (as a more-specific)
>              ...
>              2001:db8:1234:56f0:00ab:cde5:6f00:0000/128 (as a more-specific) 
>  
> If no, please explain what I missed. 
> 
> thanks a lot!
>  
> 
> 3.
> You say that aggregation doesn't make sense in 4rd-u, e.g. with the following example:
> - native IPv6: 2001:db8:1234:5670::/60, 0x02 for 64-71 bit
> - mapped IPv6: 2001:db8:1234:5670::/60, 0x03 for 64-71 bit
> But the right choice for the second line is:
> - mapped IPv6: 2001:db8:1234:5670:3000::/72 
> 
> 2001:db8:1234:5670:0300::/72, right? ;-)

Right ;-).


>  
> Thus, longest match does the job.
> 
> 
> exactly. however, my point is: as the longest-match can do the job with V octet or without it, why don't we directly use the version without it? 

That's a very different question, answered in sec 4.4 (6) of the draft:

"NOTE: The V octet is a 4rd-specific mark. Its function is to ensure that 4rd does not interfere with the choice of subnet prefixes in CE sites. For this, the V octet has its "u" and "g" bits of <xref target="RFC4291"/> both set to 1. This differs from "u" = 0, reserved for local-scope Interface IDs, and also differs from "u" = 1 and "g"= 0, reserved for unicast Interface IDs using the EUI-64 format. Bits other than "u" and "g", are proposed to be 0, giving V = 0x03. 
 With the V octet, IPv6 packets can be routed to the 4rd function within a CE node based on a /80 prefix that no native-IPv6 address can contain. 
 The V octet can also facilitate maintenance by the parameterless distinction it introduces between Tunnel packets and native-IPv6 packets. A tunnel packet has at least one of its IPv6 addresses having the V octet." 

Cheers,
RD



> 
> - maoke
>  
> (What you describe is what might have applied if we had kept the maxPsid feature. But, as you may recall, we abandoned it unanimously in Taipei.)
> 
> Cheers,
> RD 
> 
> 
> Le 2012-03-12 à 11:51, Maoke a écrit :
> 
>> 
>> 
>> 2012/3/12 Rémi Després <[e-mail]>
>> Hi, Washam,
>> 
>> Thanks for your detailed questions and comments.
>> Answers and further comments in line.
>> 
>> Le 2012-03-11 à 10:48, Washam Fan a écrit :
>> 
>> > Hi,
>> >
>> > Eventually I get a chance to review this version and have some major
>> > comments and questions as below.
>> >
>> > 1. Relationship with MAP, MAP-T, MAP-E.
>> > I thought, MAP was expected to be a generic algorithm for stateless
>> > mapping IPv4 addresses to IPv6 addresses and vice versa. I thought,
>> > MAP would apply to MAP-T, MAP-E as well as 4rd-u.
>> 
>>  The point is that 4rd-u unifies not only the address format for -T and -E, but also the header format so that a single standard becomes sufficient.
>>  The 4rd-U technique for this was presented in Taipei, but it didn't arise interest in the MAP team. Design of 4rd-u had then to become autonomous.
>> 
>> > But draft 4rd-u-04
>> > doesn't mention MAP draft.
>> 
>> 4rd-u is proposed as an alternative to the 2-standards approach of MAP.
>> It therefore needs only needs a historical reference to MAP, which is done in sec. 8.
>> 
>> > And I see the mapping rules stuff in the
>> > draft overlapped with MAP. Confused.
>> >
>> > I thought, 4rd-u is competing with MAP-T and MAP-E to some extend.
>> > Would you mind expaund on what benefits 4rd-u can gain exclusively?
>> > Ideally, there would be a seperate section or even a seperate draft
>> > for such comparison.
>> 
>> As announced, an update of draft-despres-softwire-stateless-analysis-tool will contain a comparison (now to be posted very soon).
>> 
>> An earlier comparison table was available in
>> http://www.ietf.org/mail-archive/web/softwires/current/msg03442.html
>> 
>> In any case, the main benefit is simple: 4rd-U permits, like MAP-T, to use IPv6-only middle boxes for deep packet inspection and web caches; also, like MAP-E, it ensures full IPv4 transparency.
>> 
>> 
>> > 2. NAT64+ stuff.
>> > My understanding, NAT64+ would translate 4rd tunnel packet as well as
>> > native IPv6 packet to IPv4 packet and vice verse. Right?
>> 
>> If the NAT64 is stateful per session, yes, it does translation at layer 4.
>> NAT64s that are stateless at this layer are however also possible. THis is independent from 4rd.
>> 
>> > I don't know
>> > what the CE delegated prefix in NAT64+ looks like.
>> 
>> - The delegated prefix is any prefix up to /64 that doesn't match any CE prefix (R-6 of draft-04))
>> - The source of a CE to NAT64+ packet must have the V octet for NAT64+s to be able to distinguish 4rd packets from other IPv6 packets (def of NAT64+).
>> - The format is then:
>> +-----------------------+-------+---+-----------------+------+
>> |    CE IPv6 prefix     |   0   | V |          0      |  CNP |
>> +-----------------------+-------+---+-----------------+------+
>> :      =< 64            :  >= 0 : 8 :      40         :  16  :
>> 
>> 
>> Yet, it should be clearer in the draft.
>> Thanks for this (good) question.
>> 
>> 
>> > Can the native IPv6
>> > and 4rd shared the same delegated prefix?
>> 
>> Yes. (This is the purpose of the V octet)
>> 
>> 
>> may i compare the V-octet with the MAP strategy?
>> 
>> #1. shared ipv4 address
>> take an example of delegated prefix 2001:db8:1234:5678::/64 and the IPv4 address for the CE is 0xabcde567, PSID=8. 
>> 
>> 4rd-U (with V-octet):
>> native IPv6: 2001:db8:1234:5678:0200::/72
>> mapped IPv6: 2001:db8:1234:5678:0300::/72
>> cost: IANA authority on the use of V-bit.
>> 
>> MAP (without V-octet):
>> native IPv6: 2001:db8:1234:5678::/64
>> mapped IPv6: 2001:db8:1234:5678:02ab:cde5:6780:0000/128 (as a more-specific) 
>> cost: almost none.
>> 
>> #2. exclusive ipv4 address
>> 2001:db8:1234:5670::/60, IPv4 address 0xabcde567
>> 
>> 4rd-U (with V-octet), now aggragation doesn't make sense:
>> native IPv6: 2001:db8:1234:5670::/60, 0x02 for 64-71 bit
>> mapped IPv6: 2001:db8:1234:5670::/60, 0x03 for 64-71 bit
>> cost: IANA authority on the use of V-bit; implementation cannot take the logic of longest-match!
>> 
>> MAP (without V-octet):
>> native IPv6: 2001:db8:1234:5670::/60
>> mapped IPv6: 2001:db8:1234:5670:02ab:cde5:6700:0000/128 (as a more-specific) 
>> cost: almost none. 
>> 
>> #3. exclusive ipv4 subnet
>> 2001:db8:1234:5600::/56, IPv4 address 0xabcde560~0xabcde56f
>> 
>> 4rd-U (with V-octet), now aggragation doesn't make sense:
>> native IPv6: 2001:db8:1234:5600::/60, 0x02 for 64-71 bit
>> mapped IPv6: 2001:db8:1234:5600::/60, 0x03 for 64-71 bit
>> cost: IANA authority on the use of V-bit; implementation cannot take the logic of longest-match!
>> 
>> MAP (without V-octet):
>> native IPv6: 2001:db8:1234:5600::/56
>> mapped IPv6: 2001:db8:1234:5600:02ab:cde5:6000:0000/128 (as a more-specific)
>>              2001:db8:1234:5610:02ab:cde5:6100:0000/128 (as a more-specific)
>>              ...
>>              2001:db8:1234:56f0:02ab:cde5:6f00:0000/128 (as a more-specific) 
>> cost: a number of more-specific to identify the mapped things; but it won't leaked out beyond the CE. 
>> 
>> if the well-developed longest-match can work, why should we need another mechanism? 
>> 
>> cheers,
>> maoke
>> 
>>  
>> > if Yes, how to distinguish
>> > them?
>> 
>> See above.
>> 
>> > the figure 6 seems to me it was talking about destination IPv6
>> > address derivation.
>> 
>> Right.
>> 
>> 
>> > IIRC, NAT64 supports hair pinning, doesn't it? Would NAT64+ support
>> > harpinning between 4rd tunnel packet and native IPv6 packet?
>> 
>> The only evolution of NAT64 to make it a NAT64+ is its use of tunneling instead of RFC6145 translation, for all IPv6 addresses that have the V octet. (No other behavior needs to be modified.)
>> 
>> 
>> > Personally, I'd like NAT64+ removed from the draft. It might deserve a
>> > seperate draft.
>> > This way, it would make the draft more understanding
>> > for readers who are new to 4rd-u.
>> 
>> The specification has to explain conditions in which a CE can tunnel IPv4 packets although it has no assigned public IPv4 address, even shared.
>> Explaining more what is NAT64+ is IMHO better than explaining less.
>> 
>> 
>> > 3. Fragments.
>> > The algorithm proposed in R-9, would have applied to generic NAT
>> > generally. Why it is specific to 4rd BR?
>> 
>> NATs may have to remember not only destination ports but also source ports.
>> A similar algorithm could however apply to NAT64s, but this is off 4rd scope.
>> 
>> 
>> > Anyway BR would keep fragment
>> 
>> They MAY, but AFAIK don't need to if they use R-9 algorithm.
>> 
>> > state somehow and anycase BR facing IPv4 Internet would be impossible.
>> 
>> In the CE to BR direction, destinations are full IPv4 addresses so that each fragment can be individually forwarded.
>> Sec 4.5.3 ensures that packet IDs from 2 CEs cannot be the same, so that no port-based check is needed to  ensure that no CE can spoof fragments from another CE.
>> 
>> 
>> Regards,
>> RD
>> 
>> 
>> 
>> >
>> > Thanks,
>> > washam
>> > _______________________________________________
>> > Softwires mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/softwires
>> 
>> _______________________________________________
>> Softwires mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/softwires
>> 
> 
>