Hi Cameron.

Inline please,

2011/7/28 Cameron Byrne <[email protected]>

> 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
>
> ==>I think your observation is correct.


> 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.
>
> ==>the scenario is right,  for port assignment,
2000 ports assignment per user would be fine? the algorithm allow dynamic
port assignment.


> 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.
>
> ==> stateless 464 is good in his own environment, it may not be able to
compatible with NAT64 or others, stateful 464 has advantage which could work
with others, will see.

-Hui


> This architecture is complicated.
>
> CB
>
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires

Reply via email to