Hi Cameron,
Please see inline,
> 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.
Thanks for sharing your opinion about the 4v6 encap mode as well as
other tunneling modes (e.g DS-Lite). We agree.
We make a distinction between 4v6 encap mode and tunneling mode for one
simple reason - unlike an IPv4-in-IPv6 tunnel, which would carry any
IPv4 datagram inside an IPv6 tunnel, 4v6 encap mode (i.e. 4rd) is about
carrying only certain types (particular layer4 such as TCP, UDP) of IPv4
datagram inside an IPv6 tunnel.
For ex, IP-in-IP tunnel can carry GRE encapsulated IP datagrams
or
L2TP encaped IP datagrams, whereas 4v6 encap mode can not, as
defined.
One could deduce that 6rd and DS-Lite employ IP-in-IP tunnel, whereas
4rd doesn't really, strictly speaking. Of course, it is not a
significant issue.
> I believe it is best to state
> that clearly for the 3GPP case, and move on without elaboration.
At v6ops meeting last week, there was a consensus that softwire was to
be made home for this draft (as well as various stateless NAT
solutions), if Behave was to close down. Or form a new WG for stateless
NAT/A+P solutions.
> Is the reference to RFC6053 right?
Oops. Typo. Should be 6052. Thanks for pointing it out.
> 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.
That's certainly one way to tackle this.
> 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.
Many SPs have to abide by the government/regulatory mandates for Lawful
Intercept and honor customers' request for particular
port-forwarding/opening, and they find stateless NAT in SP network being
more useful than anything else. The advantages are being better captured
in the 'motivation draft'.
http://tools.ietf.org/html/draft-operators-softwire-stateless-4v6-motiva
tion-02
Cheers,
Rajiv
> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
On Behalf
> Of Cameron Byrne
> Sent: Thursday, July 28, 2011 5:43 PM
> To: Hui Deng
> Cc: [email protected]; Wojciech Dec (wdec); Paco Cortes
> Subject: Re: [Softwires] 3gpp related comments on
draft-dec-stateless-4v6-02
>
> 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
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
