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

[Maoke <[e-mail]>]

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
>