This is hardly a hack, it's a functional requirement of a CPE, specifying
how the CPE behaves with a case of NOT having an IPv4 address = no NAT44,
in this case. It's not about overflow.

Besides that very obvious case to handle, I provided an explanation of the
value the described behaviour brings, which has also been demonstrated (per
Xing's mail). So far you have not substantiated what is the down-side of
having this functionality on a MAP CPE, other than considering it not
useful. Could you do that?

Re: your substitution: No, an SP can hardly predict which CPEs in question
need to have DS-Lite capabilities (as in support ds-lite options, et al)




On 22 November 2013 15:39, Simon Perreault <[email protected]>wrote:

> Le 2013-11-22 05:30, Wojciech Dec a écrit :
>
>  Consider the case where a MAP deployment has a need (for whatever
>> reason) to direct some CPEs to an AFTR (stateful NAT). Instead of
>> rolling out Ds-lite DHCP extensions all over
>>
>
> ...or only to the CPEs in question...
>
>
>  it is trivially simple to
>> achieve the desired effect with the above MAP CE behaviour in place.
>> This does not mean that those who want to use DS-lite dhcp extensions
>> cannot do so, if available. But it does mean that those who deploy MAP,
>> don't have to take care of mandating ds-lite dhcp extensions "just in
>> case" all over the shop.
>>
>
> s/all over the shop/to the CPEs in question/
>
> Even if there is any efficiency gain over just sending the DHCPv6 option,
> it must be so small that I don't think we should standardize this hack.
> When we can, we need to focus on one way of doing things. DHCP is well
> understood and liked by operators.
>
> It's fine if you implement the hack, but there's no need for it in the RFC.
>
>
> Simon
> --
> DTN made easy, lean, and smart --> http://postellation.viagenie.ca
> NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
> STUN/TURN server               --> http://numb.viagenie.ca
>
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires

Reply via email to