On Thu, Jul 28, 2011 at 10:48 AM, Hui Deng <[email protected]> wrote:
> Hi Cameron,
>
> You may need spend time to review it later, it's different from 6RD and
> DS-Lite,
>

I just now read it in more detail.  My first piece of feedback is that
it is too long :)  I assume future revisions will be more tight.  I
would also say that the translation part be put into a separate draft
that goes to BEHAVE.

I believe the mapped mode has some similar challenges in mobile as
DS-lite.  It is an IP in IP tunnel.  It is really a non-starter in
3GPP networks as the draft amply notes.  I believe it is best to state
that clearly for the 3GPP case, and move on without elaboration.

The translation mode looks like NAT464, and i like it NAT464 + DNS64
since it solves a real problem, as noted here
http://www.ietf.org/mail-archive/web/behave/current/msg09480.html

Is the reference to RFC6053 right?

"The operation of the 4V6 CE and
   gateway are very similar, if not identical, to that of stateless
   NAT64 as specified in RFC 6053."

So is this right?

CPE/UE (NAT46) --->ipv6 only network--> NAT64 (stateless port restricted)

And the port-set is delivered via some encoding in the IPv6 address
assigned to the UE?  This is clever.  I remain concerned about being
able to engineer stateless port allocations that sufficiently meet
everyone's needs with a limited free public IPv4 pool vs. dynamic
allocation.  I do not have much experience with stateless LSN, i am
not sure anyone has much experience at scale with port restricted
stateless?  I believe there are ways of going beyond 65k ports per
IPv4 address in stateful, what about in stateless?  I think this will
be a requirement as the IPv4 pool keeps getting stretched thin.

Right now, i feel like it would be easier for the IETF to just define
NAT464 in general and stateless translation 4V6 is a flavor of NAT464.

I understand the allure of stateless.  But, IMHO the address
multiplexing of stateful is very useful and many large SPs already run
this way, and that operational experience is very important.  The IPv6
transition space is becoming very crowded, i personally would like to
see more work to make IPv6 a true replacement for IPv4 instead of yet
another transition mechanism that meets some set for checkboxs.

This architecture is complicated.

CB
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires

Reply via email to