Subject: Re: [BEHAVE] [46translation] [Fwd: Proposal for new BEHAVE charter]

From: Fred Baker <[email-masked]>
Date: Thu, 16 Oct 2008 10:01:00 -0700

what attached message?

On Oct 16, 2008, at 9:42 AM, Magnus Westerlund wrote:

> The attached message was just sent to BEHAVE. Please send any comments
> to BEHAVE.
>
> Cheers
>
> Magnus Westerlund
>
> IETF Transport Area Director & TSVWG Chair
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone +46 8 4048287
> Färögatan 6                | Fax   +46 8 7575550
> S-164 80 Stockholm, Sweden | mailto: [email-masked]
> ----------------------------------------------------------------------
> _______________________________________________
> 46translation mailing list
> [email-masked]
> https://www.employees.org/mailman/listinfo/46translation

_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Fred Baker <[email-masked]>
Date: Thu, 16 Oct 2008 11:22:12 -0700

> The attached message was just sent to BEHAVE. Please send any comments

Andrew Yourtchenko forwarded the proposed behave charter to me; why I  
didn't get the attachment is not clear - it was clearly in the email  
he received, but there was no such attachment in the one I received.  
Mumble.

I have a point I would like to question.

The concept of "my domain" is something that came up in the interim  
meeting, concocted more or less at the last minute by Mark Townsley. I  
don't think it is very clearly explained in the proposed charter, and  
the applicability is also a concern. Which makes "and anything else is  
out of scope" a real problem.

In an IPv4/IPv6 translator, we have a succession of cases that we need  
to deal with as we proceed through the adoption curve. Work in the  
past decade has presumed islands of IPv6 in a world of IPv4, which is  
in part why the interdomain routing issues of a magic prefix such as  
proposed in section 2.1 of RFC 2765 were not seriously considered. At  
a different point in the adoption curve, we will be dealing with  
islands of IPv4 in an IPv6 world, and today some networks are dealing  
with gateways between what is essentially the public IPv4 network and  
the public IPv6 network. Since the beginning of August, we (Cisco)  
have had four public networks whose names you would recognize tell us  
that this is exactly the worldview they need. Hence, any intimation  
that we are dealing with a private domain ("my" domain) and a public  
domain are seriously dated - they reflect RFC 1918 but not technology  
coexistence and eventual transition.

Hence, what I would strongly suggest is that the concept in the  
charter be simply translation between an IPv4 network and an IPv6  
network, without any superimposition of a model of which is dominant  
and which is otherwise. I would further suggest that the model  
explicitly support both islands of either (which will have to be  
identified - the addresses of the right translator for *this* address  
and *that* address may be different, regardless of address type) and a  
global model.

I also think this has far too many words.
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 17 Oct 2008 10:07:26 +1300

I agree with Fred's comments. As in my response to Fred
a few minutes ago, the "private" side of a translator, which
I guess is the "MY" side, could be a very large network
in itself. It might be reasonable to replace "MY" by
"Administratively delimited" since it does seem that these
translators would need to be in front of a delimited domain
of some kind.

   Brian

On 2008-10-17 07:22, Fred Baker wrote:
> didn't get the attachment is not clear - it was clearly in the email he
> received, but there was no such attachment in the one I received. Mumble.
> 
> to deal with as we proceed through the adoption curve. Work in the past
> decade has presumed islands of IPv6 in a world of IPv4, which is in part
> why the interdomain routing issues of a magic prefix such as proposed in
> section 2.1 of RFC 2765 were not seriously considered. At a different
> point in the adoption curve, we will be dealing with islands of IPv4 in
> an IPv6 world, and today some networks are dealing with gateways between
> what is essentially the public IPv4 network and the public IPv6 network.
> Since the beginning of August, we (Cisco) have had four public networks
> whose names you would recognize tell us that this is exactly the
> worldview they need. Hence, any intimation that we are dealing with a
> private domain ("my" domain) and a public domain are seriously dated -
> they reflect RFC 1918 but not technology coexistence and eventual
> transition.
> 
> Hence, what I would strongly suggest is that the concept in the charter
> be simply translation between an IPv4 network and an IPv6 network,
> without any superimposition of a model of which is dominant and which is
> otherwise. I would further suggest that the model explicitly support
> both islands of either (which will have to be identified - the addresses
> of the right translator for *this* address and *that* address may be
> different, regardless of address type) and a global model.
>

---

From: Fred Baker <[email-masked]>
Date: Thu, 16 Oct 2008 14:29:26 -0700

On Oct 16, 2008, at 2:07 PM, Brian E Carpenter wrote:

> It might be reasonable to replace "MY" by

modify that to "could be administratively delimited" and I'm OK with it.
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Rémi Després <[email-masked]>
Date: Fri, 17 Oct 2008 09:22:23 +0200

I do share the view that MY would be unclear to those who didn't attend 
the interim meeting.

To avoid the ambiguity of "MY", and also some verbosity of "(possibly)
administratively delimited", wouldn't there be a solution by just
deleting MY from scenario titles, and by adding in the text "on the IPv4 
(or IPv6) Internet" where it applies?

The text would become:

1. IPv6 to IPv4 Internet, 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 on the IPv4
Internet. The translator function is intended to service a specific
IPv6 network of arbitrary size. Port translation is necessary on
the IPv4 side for efficient IPv4 address usage.

2. IPv4 from IPv6 Internet, i.e. perform translation between IPv4 and
IPv6 for packets in uni- or bi-directional flows that are
initiated from an IPv6 host on the IPv6 Internet 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. 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 on the IPv6 Internet. The 
translator function is intended to service a specific IPv4 network using 
either public or private IPv4 address space.

4. IPv6 from IPv4 Internet, i.e. perform translation between IPv4 and
IPv6 for packets in uni- or bi-directional flows that are initiated
from an IPv4 host on the IPv4 Internet 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.

RD

Fred Baker   (m/j/a) 10/16/08 11:29 PM:
>> It might be reasonable to replace "MY" by "Administratively
>> delimited" since it does seem that these translators would need to
>> be in front of a delimited domain of some kind.
> 
> modify that to "could be administratively delimited" and I'm OK with
> it. _______________________________________________ Behave mailing
> list [email-masked] https://www.ietf.org/mailman/listinfo/behave
> 
>

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 17 Oct 2008 10:56:29 +0200

I have received the comment before about this maybe being unclear from
Mark Townsley. He also suggested that we add something like this text to
explain MY:

"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.).

I didn't include that previous because I and a few other thought it was
reasonably clear anyway. I fully agree that the MY network may not be
any simple network, but it is administered by someone that makes a
concuss decision to deploy translators. There is possible to have some
restrictions on the deployment, i.e. it is not IPv4 Internet to IPv6
Internet. Maybe the above paragraph is better clarification on what is
intended than Rémi's suggestion below.

In regards to it being wordy. Yes, it is and I don't see how one easily
can make it less so without removing information that I want to include.
Many IETF WG charters are so short and void of information that no
outsider who wasn't part of the chartering process can determine what it
really says. But, if someone has a bright idea how to accomplish that
please write up a proposal.

Cheers

Magnus

-- 

Magnus Westerlund

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 17 Oct 2008 11:51:24 +0200

On 16 okt 2008, at 18:42, Magnus Westerlund wrote:

> 2. IPv6 Internet to MY IPv4, i.e. perform translation between IPv4 and
>   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.

Isn't this trivial: just add "fake" AAAA records manually and do SIIT  
(1-to-1)? (Same thing for 4.)

> 3. MY IPv4 to IPv6 Internet, i.e. perform translation between IPv4 and
>   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.

Will this be a separate solution or integrated with v6-to-v4?

> All translation solutions shall be capable of handling flows using  
> TCP,
> UDP, DCCP, and SCTP.

I disagree. This is a quick fix effort. DCCP and SCTP have essentially  
zero deployment, making these "MUST" will slow down the work without a  
real world benefit. Same thing for multicast. There is no end-to-end  
multicast on the internet today, so there is no vicious deployment  
cycle to break with translation.
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 20 Oct 2008 16:52:11 +0200

Inline,

> (1-to-1)? (Same thing for 4.)

Probably, but we need to document it so that people don't get inventive.

> Will this be a separate solution or integrated with v6-to-v4?

A very good question that I intended to give the WG a while to determine.

> 
>> All translation solutions shall be capable of handling flows using TCP,
>> UDP, DCCP, and SCTP.
> 
> multicast on the internet today, so there is no vicious deployment cycle
> to break with translation.

Lets start with multicast. I agree about that over the general Internet
there isn't deployment. However, if for example Cisco is going to deploy
a new office that only has IPv6, then they likely need multicast support
towards the rest of their IPv4 network to support there conferencing
tools. That is why I am very hesitant to leave it out without first
saying that it is to hard.

When it comes to our "new" transport protocol, I don't like to make
deployment even harder. If they slow this work down significantly I am
okay to cut them out. But I don't believe that will be the case. The
specification for DCCP is already done for IPv4, and the reality is that
if you can support TCP and UDP, you have all the components for DCCP.
SCTP is not yet ready when it comes to v4v4 translation.

Cheers

Magnus Westerlund