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

From: Washam Fan <[email-masked]>
Date: Sun, 11 Mar 2012 17:48:58 +0800

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. But draft 4rd-u-04
doesn't mention MAP draft. 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.

2. NAT64+ stuff.
My understanding, NAT64+ would translate 4rd tunnel packet as well as
native IPv6 packet to IPv4 packet and vice verse. Right? I don't know
what the CE delegated prefix in NAT64+ looks like. Can the native IPv6
and 4rd shared the same delegated prefix? if Yes, how to distinguish
them? the figure 6 seems to me it was talking about destination IPv6
address derivation.

IIRC, NAT64 supports hair pinning, doesn't it? Would NAT64+ support
harpinning between 4rd tunnel packet and native IPv6 packet?

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.

3. Fragments.
The algorithm proposed in R-9, would have applied to generic NAT
generally. Why it is specific to 4rd BR? Anyway BR would keep fragment
state somehow and anycase BR facing IPv4 Internet would be impossible.

Thanks,
washam

---

From: Rémi Després <[email-masked]>
Date: Mon, 12 Mar 2012 09:19:17 +0100

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 :

> 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

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.

> 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)

> if Yes, how to distinguish
> them?

See above. 

> the figure 6 seems to me it was talking about destination IPv6
> address derivation.

Right.

> 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.)

> seperate draft.
> This way, it would make the draft more understanding

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.

> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires

---

From: Washam Fan <[email-masked]>
Date: Mon, 12 Mar 2012 17:10:36 +0800

Hi Remi,

Thanks for the clarification. Only one response,

> NATs may have to remember not only destination ports but also source ports.

Yes. I agree.

> A similar algorithm could however apply to NAT64s, but this is off 4rd scope.

So curious why a similar algorithm is NOT there for NATs.

Thanks,
washam

---

From: Maoke <[email-masked]>
Date: Mon, 12 Mar 2012 10:51:26 +0000

2012/3/12 Rémi Després <[email-masked]>

>  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
> As announced, an update of draft-despres-softwire-stateless-analysis-tool
> will contain a comparison (now to be posted very soon).
>
> 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.
> - 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:
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

> 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.)
>
>
> The specification has to explain conditions in which a CE can tunnel IPv4
> packets although it has no assigned public IPv4 address, even shared.
> 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

---

From: Rémi Després <[email-masked]>
Date: Mon, 12 Mar 2012 18:00:35 +0100

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.

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.
If no, please explain what I missed. 

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 
Thus, longest match does the job.

(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 :

> 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):
> mapped IPv6: 2001:db8:1234:5678:02ab:cde5:6780:0000/128 (as a more-specific) 
> cost: almost none.
> 
> cost: IANA authority on the use of V-bit; implementation cannot take the logic of longest-match!
> 
> MAP (without V-octet):
> mapped IPv6: 2001:db8:1234:5670:02ab:cde5:6700:0000/128 (as a more-specific) 
> cost: almost none. 
> 
> cost: IANA authority on the use of V-bit; implementation cannot take the logic of longest-match!
> 
> MAP (without V-octet):
>              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
> 
>

---

From: Maoke <[email-masked]>
Date: Tue, 13 Mar 2012 00:59:44 +0000

hi Remi,

> 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.

> 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

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.

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.

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!

> - mapped IPv6: 2001:db8:1234:5670:3000::/72

2001:db8:1234:5670:0300::/72, 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?

- 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
>
>
>>  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
>> 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,
>> - 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:

---

From: Rémi Després <[email-masked]>
Date: Tue, 13 Mar 2012 09:33:52 +0100

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

> oh, yes! i made the typo, falling into the EUI-64 case. MAP cites RFC6052 format for IID, while the latter states:
> thanks a lot for pointing out the mistake! the corresponding example should be corrected as:
> 
> #1. shared ipv4 address
> mapped IPv6: 2001:db8:1234:5678:00ab:cde5:6780:0000/128 (as a more-specific) 
> cost: almost none.
> 
> mapped IPv6: 2001:db8:1234:5670:00ab:cde5:6700:0000/128 (as a more-specific) 
> cost: almost none. 
> 
>              2001:db8:1234:56f0:00ab:cde5:6f00:0000/128 (as a more-specific) 
>  

Right ;-).

> 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