Re: [v4v6interim] [BEHAVE] Proposal for new BEHAVE charter

[Magnus Westerlund <[e-mail]>]

Please see inline.

Margaret Wasserman skrev:


> 
>> The goal of this work is to encourage migration to IPv6 and compliance
>> with the UNSAF [RFC 3424] considerations. To support deployments where
>> communicating hosts require using different address families (IPv4 or
>> IPv6), address family translation is needed to establish communication.
>> BEHAVE will coordinate with the V6ops WG in this work.
> 
> I think it should be made clearer here whether the translation documents
> will be written in the v6ops WG or behave.  I _think_ this is intended
> to say that the documents will be written in behave, and that the behave
> WG will get input and review regarding operational  requirements and
> deployability from the v6ops WG, but I'd like to see that made clearer.

Yes, that is was intended.

> 
>> The BEHAVE WG will design solutions for the following four translation
>> scenarios; other scenarios are out of scope:
>>
>> 1. MY IPv6 to IPv4 Internet, i.e. perform translation between IPv4 and
> 
> "MY" should be expanded or explained before it is first used.

Okay, do you think the following is good enough?

"My" IPv4 or IPv6 network in the descriptions below refer to a network
with a clearly identifiable administrative domain (e.g., an enterprise
campus network, a mobile operator's cellular network, a residential
subscriber network, etc.).



> 
>>   IPv6 for packets in uni- or bi-directional flows that are
>>   initiated from an IPv6 host towards an IPv4 host. The
>>   translator function is intended to service a specific
>>   IPv6 network of arbitary size. Port translation is necessary on
>>   the IPv4 side for efficient IPv4 address usage.
>>
>> 2. IPv6 Internet to MY IPv4, i.e. perform translation between IPv4 and
>>   IPv6 for packets in uni- or bi-directional flows that are
>>   initiated from an IPv6 host towards an IPv4 host.  The translator
>>   function services is intended to service a specific IPv4 network
>>   using either private or public IPv4 addresses. Because this scenario
>>   has different constraints compared to (1), the WG should attempt to
>>   design a simpler solution with less impact on applications.
>>
>> 3. MY IPv4 to IPv6 Internet, i.e. perform translation between IPv4 and
>>   IPv6 for packets in uni- or bi-directional flows that are initiated
>>   from an IPv4 host towards an IPv6 host. The translator function is
>>   intended to service a specific IPv4 network using either public or
>>   private IPv4 address space.
>>
>> 4. IPv4 Internet to MY IPv6, i.e. perform translation between IPv4 and
>>   IPv6 for packets in uni- or bi-directional flows that are initiated
>>   from an IPv4 host towards an IPv6 host. The translator function is
>>   intended to service a specific IPv6 network where selected IPv6 hosts
>>   and services are to be reachable.
> 
> I would also like to us write (at least) two NAT-related documents that
> aren't listed here:
> 
> (1) A document that offers advice on how/when to deploy these translation
> mechanisms vs. other choices.  I think this document would cover topics
> such as:
> 
>     - If the infrastructure will support dual stack and you are running out
>           of IPv4 addresses, NAT IPv4 and leave IPv6 alone.
>     - The advantages of placing NATs closer to the edges of the network
> 

There has been discussion around a framework document already and I
think that makes sense. I do want to know if anyone is disagreeing.


> (2) An explanation of how to do IPv6 <=> IPv6 NAT.  It am convinced that
> there are some people who will choose to do this for the same reasons that
> people with plenty of IPv4 addresses choose to use IPv4 <=> IPv4 NATs
> today.  I think we could write a document that says something like:  IPv6
> <=> IPv6 NATs are not really necessary, don't provide any concrete
> advantages
> that can't be obtained through less disruptive means, and are not
> recommended
> by the IETF, but if you are planning to do this anyway, please do it
> right (don't
> include port translation, use algorithmic address mapping if possible,
> instead
> of state tables, etc.).

Considering the discussion so far I see some interest. But it seem to
not be a priority item. Lets get the important things going first before
using up a lot of resources in this discussion.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone [phone]
Färögatan 6                | Fax   [phone]
S-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------
_______________________________________________
v4v6interim mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/v4v6interim