Simon,

>>> Med: The rationale we adopted in this draft is as follows:
>>> 
>>> * there are three major flavors: full stateful, full stateless, and binding 
>>> mode
>>> * all these modes can support assigning a full or a shared IPv4 address
>> 
>> now you got me thinking, are these really the right modes from a CPE 
>> perspective?
>> 
>> let me try to explain, with my CPE implementor hat on, what "modes" would 
>> make sense?
>> 
>> - NAT placement. do I need a NAT on the CPE or not?
>>   (no NAT && no IPv4 address == DS-lite)
>> - full IPv4 address assigned.
>>   I can assign the IPv4 address to the tunnel endpoint interface, and use 
>> that address for
>>   local applications, and as the outbound address of the NAT
>>   (mechanisms: MAP, Public 4over6)
>> - IPv4 prefix assigned:
>>   I need to disable the CPE NAT, and use the assigned IPv4 prefix as my LAN 
>> side DHCPv4 pool
>>   (mechanism: MAP)
>> - Shared IPv4 address.
>>   I must enable a local NAT, I cannot assign the IPv4 address on the "WAN" 
>> interface, but only use it
>>   for the outbound side of the NAT.
> 
> Interesting... But note that even just implementing MAP alone would generate 
> three of these "implementation modes". I would still like to see this list 
> added to an "implementation considerations" section. Stuff like "you can't 
> assign a partial address to a tunnel interface" may not be obvious to 
> implementers.
> 
>> then there might be a sub-modes for "tunnel endpoint determination" i.e. how 
>> to determine an IPv6 tunnel end point address given an IPv4 destination 
>> address and port.
>> 1) algorithmic (MAP)
>> 2) configured (Public 4over6, LW46, DS-lite)
>> 
>> and a sub-mode for IPv4 address configuration:
>> 1) As "native IPv4"
>>     (Public4over6, LW46)
>> 2) Embedded Address
>>     (MAP)
>> 3) None
>>    DS-lite
>> 
>> does this make sense?
> 
> Totally appropriate for an "implementation considerations" section IMHO.

I'm suggesting to replace the current drafts "state*, binding modes" with these 
modes.

cheers,
Ole

_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

Reply via email to