Subject: [BEHAVE] Address questions on draft-baker-behave-v4v6-framework-01

From: Magnus Westerlund <[email-masked]>
Date: Thu, 19 Mar 2009 19:13:08 +0100

Hi,

I read this draft and the other translation drafts in BEHAVE. In regards
to the framework, I ended up with one big question around addresses when
using a stateless translator.

                --------          --------
              //  IPv4  \\      //  IPv6  \\
             /   Domain   \    /   Domain   \
            /             +----+      +--+   \
           |              |XLAT|      |S3|    |  Sn: Servers
           | +--+         +----+      +--+    |  Hn: Clients
           | |S1|         +----+              |
           | +--+         |DNS |      +--+    |  XLAT: translator
            \     +--+    +----+      |H3|   /   DNS:  DNS Server
             \    |H1|    /    \      +--+  /
              \   +--+   /      \          /
             /            \    /            \
            /             +----+             \
           | +--+         |XLAT|     +--+     |
           | |S2|         +----+     |S4|     |
           | +--+         +----+     +--+     |
           |      +--+    |DNS |       +--+   |
            \     |H2|    +----+       |H4|  /
             \    +--+    /    \       +--+ /
              \\        //      \\        //
                --------          --------

In the above example if H3 and S1 is communicating and the translator is
 stateless. I do become uncertain about the address and thus resulting
routing that is used for the S1->XLAT->H3 in the XLAT -> H3 step.

I have the impression that H3 will have to been assigned a IPv4 related
IPv6 address that the XLAT will know that the IPv4 pool address is
related to a particular IPv6 address assigned to H3. Is this
understanding correct?

When we come to related addresses isn't this actually state? Either the
translator has state that says IPv4 address X <-> IPv6 address Y' where
Y' is H3's address. Alternatively it seems possible to use an address
that the XLAT knows how to do automatic translate to an IPv6. A Mapped
IPv6 with another prefix that routes from the XLAT to H3 if H3 has been
assigned the specific mapped address. But I guess that then the state
ends up in the routing state of the IPv6 domain.

So stateless is only in the meaning that you don't need to track
sessions state. You need some address state it appears to me somewhere.
Are it at all practical to have it somewhere else than in the XLAT
function?

I think this part could be better clarified in the document.

Mvh

Magnus Westerlund
As individual contributor

---

From: Fred Baker <[email-masked]>
Date: Thu, 19 Mar 2009 11:40:05 -0700

> using a stateless translator.

That depends, of course, in part on how this is deployed. If the  
translators are using different prefixes to embed the IPv4 address  
into, routing, in both directions, is very specifically through the  
translator whose prefix one is using. If the translators are using the  
same prefix, routing could just as easily be asymmetric - S1->H3 goes  
through one translator (or is load-shared across both of them) and H3- 
 >S1 goes through the other (or is load-shared).

That is an important consideration when it comes to stateful  
translation as is proposed for general IPv6 clients reaching IPv4  
servers. The destination address is the same format - IPv4 embedded in  
IPv6 - but the source address is a generic IPv6 address, which means  
that the stateful translator will have (much like NAT4/4) session  
state that overloads an IPv4 address with data from many IPv6 sources,  
and disambiguates that using the source port. I won't say that it  
can't load-share, but we don't plan to propose the necessary state  
management protocols.

> related to a particular IPv6 address assigned to H3. Is this

In this context, which is to say "stateless translation", yes, H3 will  
have an address that embeds an IPv4 address inside some IPv6 prefix.  
BTW, this is exactly the same behavior as SIIT; we're just using a  
different prefix.

> I think this part could be better clarified in the document.

Maybe you could suggest text.

The reference to "state" is a reference to dynamic state maintained in  
the translator. In the words of draft-baker-behave-v4v6- 
framework-02.txt:

    State:  "State" refers to dynamic information that is stored in a
       network element.  For example, if two systems are connected by a
       TCP connection, each stores information about the connection,
       which is called "connection state".  In this context, the term
       refers to dynamic correlations between IP addresses on either  
side
       of a translator, or {IP Address, Transport type, transport port
       number} tuples on either side of the translator.

In the stateful mode, which connects a system using a generic IPv6  
address with an IPv4 system, as I said above the translator will be  
forced to maintain dynamic state. In the stateless mode, there is no  
such state maintained by the translator - there is an algorithmic  
relationship between the IPv4 address, the prefix assigned by the  
operator, and the resulting IPv6 address.

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 19 Mar 2009 20:00:47 +0100

Fred Baker skrev:
> translators are using different prefixes to embed the IPv4 address into,
> routing, in both directions, is very specifically through the translator
> whose prefix one is using. If the translators are using the same prefix,
> routing could just as easily be asymmetric - S1->H3 goes through one
> translator (or is load-shared across both of them) and H3->S1 goes
> through the other (or is load-shared).
> 
> That is an important consideration when it comes to stateful translation
> as is proposed for general IPv6 clients reaching IPv4 servers. The
> destination address is the same format - IPv4 embedded in IPv6 - but the
> source address is a generic IPv6 address, which means that the stateful
> translator will have (much like NAT4/4) session state that overloads an
> IPv4 address with data from many IPv6 sources, and disambiguates that
> using the source port. I won't say that it can't load-share, but we
> don't plan to propose the necessary state management protocols.
> 

Maybe, but actually on part of my confusion was around the IPv6 address
used in the IPv6 domain and how you make the traffic going from the
translator to the intended host.

> the translator. In the words of draft-baker-behave-v4v6-framework-02.txt:
> 
>       refers to dynamic correlations between IP addresses on either side

When rereading:

   Stateless Translation:  A translation algorithm that is not
      "stateful" is "stateless".  It may require configuration of a
      static translation table, or may derive its needed information
      algorithmically from the messages it is translating.

I do see that it mention the static translation table. I think this
would be clear if there was discussion more about the address and
related routing in the IPv6 domain to get things back.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Fred Baker <[email-masked]>
Date: Thu, 19 Mar 2009 13:41:59 -0700

> translator to the intended host.

Let me ask you this:

when you have an SMB behind a NAT and a hugely complex internal  
network, and you assign an IPv4 address to an IPv4 host, how do you  
get the traffic from the NAT to the host?

Hint: folks who answer such questions regularly are often familiar  
with acronyms like "OSPF", "IS-IS", "BGP", and "RIP".

The same is true in IPv6.

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 19 Mar 2009 22:12:53 +0100

Fred Baker skrev:
> when you have an SMB behind a NAT and a hugely complex internal network,
> and you assign an IPv4 address to an IPv4 host, how do you get the
> traffic from the NAT to the host?
> 
> Hint: folks who answer such questions regularly are often familiar with
> acronyms like "OSPF", "IS-IS", "BGP", and "RIP".
> 

I was not asking for an explanation of routing, but I am missing any
discussion of the address issue in the framework document. Do also
remember that some people that are going to reading this are coming from
the higher layers in the stack and not the lower ones.

To me it seems to be several choices based on what type of addresses you
are using. They are also directly affecting the technical choice or at
least description of the solution. You are spending a reasonable amount
of space to discuss the embedded addresses in the way of going from a v6
host to the translator, but not about the other direction.

Am I completely wrong in that the choices for stateless are:

1. Put a table in the XLAT and use any IPv6 address for the host that
you want to map a IPv4 XLAT pool address.

2. Use algorithmic mapping of the IPv4 pool address into a specific
prefix and that seem to be possible to in several ways
   a. mapped address
   b. IPv4 related

So don't you think there is reason to have some discussion in the
document about this?

Cheers

Magnus Westerlund
(as individual contributor)

---

From: Fred Baker <[email-masked]>
Date: Thu, 19 Mar 2009 15:17:23 -0700

> the higher layers in the stack and not the lower ones.

Perhaps. So I am looking at page 19, the page you copied Figure 7 from.:

                 --------          --------
               //  IPv4  \\      //  IPv6  \\
              /   Domain   \    /   Domain   \
             /             +----+      +--+   \

      Figure 7: Service provider translation with multiple interchange
                                   points

The immediately following bit of text reads:

    Since [RFC4291] specifies that routable IPv6 prefixes are 64 bits or
    shorter apart from host routes, one wishes to allocate each customer
    a /64 mapped to a few IPv4 addresses and a shorter prefix for his
    general use.  The customer's CPE advertises the two prefixes into  
the
    IPv6 routing domain to attract relevant traffic.  The translator
    advertises the mapped equivalent of an IPv4 default route into the
    IPv6 domain to attract all other traffic to it, for translation into
    the IPv4 routing domain.  It also advertises an appropriate IPv4
    prefix aggregating the mapped prefixes into the IPv4 domain to
    attract traffic intended for these customers.

So, to put such an address in one's network, one configures it on the  
host (DHCP, manual configuration, whatever) and configures the host's  
router with a prefix that contains that host, or a static route to the  
host. The router injects the prefix or the static route into other  
routing in the manner this paragraph describes, and the packets get  
there.

Were you looking for something else?

> you want to map a IPv4 XLAT pool address.

If you want to replace a stateless model with a configured stateful  
model, yes, you could do that. Doing so would be different than what  
is being proposed here.

> So don't you think there is reason to have some discussion in the

You see, I think there is. In fact, it jumps out of the page at me. So  
I need for you to help me see how you managed to confuse a "stateless"  
algorithm with a "configured stateful" algorithm, and how better to  
phrase this already-existing discussion so that you will understand it.

Please suggest text.

---

From: Xing Li <[email-masked]>
Date: Fri, 20 Mar 2009 10:30:44 +0800

>> the higher layers in the stack and not the lower ones.

Some additional information.

(1) The address mapping and translation examples both for the stateless 
and stateful are discussed in the translation document. You may also see 
page 10 and page 17 in the presentation of  
http://www.ietf.org/proceedings/08nov/slides/behave-6.pdf 

(2) Concerning the routing issues, the Xlate follows the "more specific 
win" principle.

(3) The reference of the stateless translation can be found in the draft 
http://tools.ietf.org/html/draft-xli-behave-ivi-01

xing

>    general use.  The customer's CPE advertises the two prefixes into the
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
>
>

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 20 Mar 2009 09:32:47 -0700

Fred Baker skrev:
> routing in the manner this paragraph describes, and the packets get there.
> 

I was looking for the address discussion for the direction translator v6
domain host. I don't think that is clear in the SIIT document either,
and as you will have different prefixes or type of addresses depending
on direction I think this warrants as much discussion as the other
direction.

> model, yes, you could do that. Doing so would be different than what is
> being proposed here.
> 
> You see, I think there is. In fact, it jumps out of the page at me. So I
> need for you to help me see how you managed to confuse a "stateless"

I brought up the configured state solution because it wasn't clear which
type of addressing you suggest one uses in the translator -> v6 host.
This made my head spin around possible solutions.

> Please suggest text.

I think the information may be there but a bit dense unless you actually
have the model in your head. Now that I re-read section 2.2 and these
specific paragraphs I do understand the difference between them.

   For the representation of the IPv4 addresses in the IPv6 Internet in
   both stateless and stateful modes, the PREFIX is advertised in the
   IPv6 network by the translator, and packets addressed to this PRFIX
   will be routed to the translator.  This PREFIX is configured for each
   translator, and DNS ALG.

   For the representation of the IPv6 addresses in the IPv4 Internet in
   the stateless mode, more specifics (defined as IVI6) inside this
   PREFIX are advertised in the ISP's IPv6 network by the CPE routers,
   and packets addressed to the more specifcs inside this PREFIX will be
   routed to the IPv6 end systems.  This PREFIX is not used for the
   representation of the IPv6 addresses in the IPv4 Internet in the
   stateless mode.

However, I am missing some introduction text that discusses the
different prefixes for traffic to the translator and from the translator
in the v6 domain.

Cheers

Magnus Westerlund

---

From: Xing Li <[email-masked]>
Date: Mon, 23 Mar 2009 09:47:20 +0800

> host to the translator, but not about the other direction.

some additional information.

1. From a v6 host to the translator, we use same method both for 
stateless and stateful modes
1.1 In the stateless mode: embed global IPv4 addresses in an IPv6 
network’s prefix
1.2 In the stateful mode: embed global IPv4 addresses in an IPv6 
network’s prefix

2. From a v4 host to the translator, we use different methods for 
stateless ans stateful modes
2.1 In the stateless mode: embed a subset of the ISP’s IPv4 addresses in 
an IPv6 network’s prefix
2.2 In the stateful mode: use session initiated mapping table in the 
translator to do the translation.
> you want to map a IPv4 XLAT pool address.
yes, in the stateful mode.
> prefix and that seem to be possible to in several ways
see above.
> So don't you think there is reason to have some discussion in the

we will add some discussion in the next version. thanks.

xing