Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe

Hi Ole,

Whichever state is selected, NAT is certainly fundamental to how the state will operate and so we tried to weave it into the functional description. I'm not sure that provisioned NAT info enough to be able to use to unambiguously define with operating 'mode' (for want of a better word) to use.

One of the reasons for the use of state in the draft is try and define the operating modes with as little overlap as possible (it's not 100%, but there's only 1 exception at the moment for binding mode and MAP1:1). From this, then it is easier to align the specific solution names to the state characteristics.

But, with what you've suggested, there is more overlap, i.e. both 2&4 have NAT functions that are supported by two different mechanisms.

However, what you've said does raise the following point:

The way that state is described in the draft at the moment is actually taken from a concentrator perspective. This could be taken to be almost the inverse of the amount of state that is required from the CPEs perspective (i.e. if all of the state is in the providers network (DS-Lite), then the CPE doesn't need it. If the providers network has less state ('per-customer', 'stateless'), then the CPE needs to have more - i.e. dynamic state table for NAT, configuration for local IPv4/port set, MAPing rules etc.

Would describing the different states more from the CPE's perspective make this clearer?

Cheers,
Ian

-----Original Message-----
From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Behalf Of Ole Trøan
Sent: Samstag, 1. Dezember 2012 09:48
To: Simon Perreault
Cc: softwires@ietf.org
Subject: Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe

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