Subject: [shara] First draft of the shara use cases for review

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 16 Mar 2009 21:04:34 +0100

Hi,

I have done a first version of the slides describing the SHARA use cases
Find them at:
http://www.ietf.org/proceedings/09mar/slides/shara-0.pdf

Comments are welcome.
The suppose to reflect the recent disucssion on scenarios on the ml

Regards, marcelo

---

From: <[email-masked]>
Date: Tue, 17 Mar 2009 09:23:00 +0100

Dear Marcelo, all

Thank you for these slides. Please find below some comments:

- Slide 4: 
1/ To avoid confusion with overlapped port ranges, I suggest to have something like (IP1, PR1), (IP1, PR2) etc, assigned to port restricted devices instead of P1...P2, P2...P2 notation. 
2/ Port Range Router is not **necessarily** connected to what you call "rest of Internet IPv4".
3/ What is the role of the two represented PRRs? 

- Slide 5: Idem as slide 4

- Slide 7: 
1/ Why you need a tunnel between represented two routers? 

FYI, additional IPv6-related use cases are defined in draft-boucadair-behave-ipv6-portrange-01. Two modes are defined: encapsulation and translation mode:
The encapsulation mode uses a stateless function called SMAP (Stateless A+P Mapping). A SMAP function may be embedded in a PRR or a port restricted device. A port restricted device may be a CPE, PDA, terminal, etc. I reproduce hereafter these use cases:

- Use IPv6 for incoming traffic destined to a shared IP address. No alteration is required for outgoing traffic.

                  +----------+
         --IPv4---|----------|------------IPv4--------------------\
         ---------|----------|------------------------------------/
                  |          |
                  | +------+ |               +------+
                  | |      | | /----IPv6-----|      |
         /--IPv4--| | SMAP | |//---IPv4----  | SMAP |/---IPv4----
         \--------| |      | |\\-----------  |      |\-----------
                  | |      | | \-------------|      |
                  | +------+ |               +------+
                  |          |
                  +----------+
                     node A                    node B

- IPv6 is used in both directions

                       +------+             +------+
                       |      |----IPv6---\ |      |
           ----IPv4---\|      |----IPv4---\\|      |----IPv4---\
           -----------/|      |-----------//|      |-----------/
                       |      |-----------/ |      |
                       | SMAP |             | SMAP |
                       |      | /----IPv6---|      |
           /---IPv4----|      |//---IPv4----|      |/---IPv4----
           \-----------|      |\\-----------|      |\-----------
                       |      | \-----------|      |
                       +------+             +------+
                        node A               node B

Two interconnection scenarios may be envisaged as listed below:

- Interconnection scenario 1:

+------+           +------+   +--------+   +------+           +------+
|      |--IPv6---\ |      |   |        |   |      |---IPv6--\ |      |
|      |--IPv4---\\|      |---|-IPv4---|--\|      |---IPv4--\\|      |
|      |---------//|      |---|--------|--/|      |---------//|      |
|      |---------/ |      |   |Internet|   |      |---------/ |      |
| SMAP |           | SMAP |   |  IPv4  |   | SMAP |           | SMAP |
|      | /---IPv6--|      |   |        |   |      | /---IPv6--|      |
|      |//---IPv4--|      |/--|-IPv4---|---|      |//--IPv4---|      |
|      |\\---------|      |\--|--------|---|      |\\---------|      |
|      | \---------|      |   |        |   |      | \---------|      |
+------+           +------+   +--------+   +------+           +------+
  Source            node A                  node B           Destination

- Interconnection scenario 2:

   +------+             +------------+              +------+
   |      |             |            |              |      |
   |      |----IPv6-----|----IPv6----|----IPv6----\ |      |
   |      |----IPv4-----|------------|----IPv4----\\|      |
   |      |-------------|------------|------------//|      |
   |      |-------------|------------|------------/ |      |
   | SMAP |             | Internet v6|              | SMAP |
   |      | /-----IPv6--|------------|-----IPv6-----|      |
   |      |//---IPv4----|------------|-------IPv4---|      |
   |      |\\-----------|------------|--------------|      |
   |      | \-----------|------------|--------------|      |
   |      |             |            |              |      |
   +------+             +------------+              +------+
    Source                                            Destination

Cheers
Med

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de marcelo bagnulo braun
Envoyé : lundi 16 mars 2009 21:05
À : [email-masked]
Objet : [shara] First draft of the shara use cases for review

Hi,

I have done a first version of the slides describing the SHARA use cases Find them at:
http://www.ietf.org/proceedings/09mar/slides/shara-0.pdf

Comments are welcome.

Regards, marcelo

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

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 19 Mar 2009 18:11:02 +0100

Hi,

thanks for the comments

> 1/ To avoid confusion with overlapped port ranges, I suggest to have something like (IP1, PR1), (IP1, PR2) etc, assigned to port restricted devices instead of P1...P2, P2...P2 notation. 
done

> 2/ Port Range Router is not **necessarily** connected to what you call "rest of Internet IPv4".
It, is by definition of the Rest of the Internet :-)
No, more seriously, I basically was including there all the rest of the 
IP world, so, by definition, it is connected to the rest of the 
internet. But i understand that you find this confusing somehow. If you 
explain what  bothers you, i can try to fix it.
> - Slide 5: Idem as slide 4
I understand that you have a hierarchy of Port routers, so that a port 
router on the top of the hierarchy delegates a  port raneg to another 
port router, which in turn delegated sub ranges of this initial port 
range to other port routers or to port resticted nats or to end hosts, 
and that is what i want to describe by including multiple port routers 
and the tunnel technology between them... makes sense?

> 1/ Why you need a tunnel between represented two routers? 
see the answer above

> FYI, additional IPv6-related use cases are defined in draft-boucadair-behave-ipv6-portrange-01. Two modes are defined: encapsulation and translation mode:
AFAIU, the encapsulation mode is covered in Use case #2 and the 
translation mode is covered in Use case #3
I mean, in use case #2, IPv4 over IPv6 tunnels are considered and in the 
use case#3 we cover the case where the IPv6 client wants to connect to 
an IPv4 server.

I agree that the NAT64 function can be located in different parts of the 
network, but i understand than the closer we keep the nat function tothe 
customer, the better.

Do you think i am missing something?

Regards, marcelo
PS: Updated slides with the modification and slide number to facilitate 
comments have been posted
http://www.ietf.org/proceedings/09mar/slides/shara-0.pdf

Regards, marcelo

---

From: <[email-masked]>
Date: Fri, 20 Mar 2009 07:58:36 +0100

Hi Marcelo, all,

Please see inline.

Cheers
Med

-----Message d'origine-----
De : marcelo bagnulo braun [mailto:[email-masked]] 
Envoyé : jeudi 19 mars 2009 18:11
À : BOUCADAIR Mohamed RD-CORE-CAE
Cc : [email-masked]
Objet : Re: [shara] First draft of the shara use cases for review

Hi,

thanks for the comments

done

> 2/ Port Range Router is not **necessarily** connected to what you call "rest of Internet IPv4".
It, is by definition of the Rest of the Internet :-) No, more seriously, I basically was including there all the rest of the IP world, so, by definition, it is connected to the rest of the internet. But i understand that you find this confusing somehow. If you explain what  bothers you, i can try to fix it.

Med: The location of the PRR in the Service Provider domain (i.e. AS) is not necessarily at interconnection border (i.e. near to an ASBR) even if in some scenarios it can be (e.g. IPv6 context). But at the level of the presentation, this subtleties should be avoided. To avoid confusion, I suggest that a PRR node to be drawn inside the service provider cloud. This cloud is then connected to what you call the rest of Internet.

> - Slide 5: Idem as slide 4
I understand that you have a hierarchy of Port routers, so that a port router on the top of the hierarchy delegates a  port raneg to another port router, which in turn delegated sub ranges of this initial port range to other port routers or to port resticted nats or to end hosts, and that is what i want to describe by including multiple port routers and the tunnel technology between them... makes sense?

Med: Several PRRs are required to be deployed inside a service domain realm. The current proposed solution does not assume a hierarchy between these PRRs. But in some scenarios, two PRRs **may** intervene in the delivery of connectivity services. These cascaded PRRs is required because the involved parties are not managed by the same PRR. BTW, we can imagine a hierarchy between PRRs, but this is solution specific and should IMHO avoided in this slot.

see the answer above

> FYI, additional IPv6-related use cases are defined in draft-boucadair-behave-ipv6-portrange-01. Two modes are defined: encapsulation and translation mode:
AFAIU, the encapsulation mode is covered in Use case #2 and the translation mode is covered in Use case #3 I mean, in use case #2, IPv4 over IPv6 tunnels are considered and in the use case#3 we cover the case where the IPv6 client wants to connect to an IPv4 server.

I agree that the NAT64 function can be located in different parts of the network, but i understand than the closer we keep the nat function tothe customer, the better.

Med: Fine. The translation mode is not covered. See the following flow example:

        +--+             +---+            +-----+               +--+
        |M1|             |CPE|            |i-PRR|               |RM|
        +--+             +---+            +-----+               +--+
          |                |                 |                    |
          |==(1)IPv6_Out==>|==(2)IPv6_Out===>|==(3)Pub_IPv4_Out==>|
          |                |                 |                    |
          |<==(6)IPv6_In===|<==(5)IPv6_In====|<===(4)Pub_IPv4_In==|
          |                |                 |                    |

                        Figure 19: Translation Mode

Cheers,
Med

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 20 Mar 2009 16:54:03 +0100

> Med: Several PRRs are required to be deployed inside a service domain realm. The current proposed solution does not assume a hierarchy between these PRRs. But in some scenarios, two PRRs **may** in…

by hierarchy i meant that a PRR1 has IP1 and PR1 and there is another 
PRR2 which gets IP1 and PR2 from PRR1, so that PR2 is included in PR1. I 
understnad that all approaches support this, so that i why i thought 
this was solution agnostic... am i wrong?

> Med: Fine. The translation mode is not covered. See the following flow example:

but this is covered in use case 3 afacis. The main difference is that 
the v4 v6 translator is located deeper into the ISP network. Now, i fail 
to see how this fits in the shara case, since i guess this would be the 
CGN variation of the v4 v6 translator, rather than the share variations, 
if you see what i mean.

In other words, in the v4v6 transaltor case, you can either place it 
near the customer, whoch would be the sahra flavor of it, or you can 
place it in the ISP network, which would be the CGN flavor of it.

What you depict in the figure seems the CGN flavor, i.e. the translator 
is far from the client, so i would assume this is not partof the shara 
effort.

what am i missing?

Regards, marcelo

---

From: <[email-masked]>
Date: Fri, 20 Mar 2009 18:12:31 +0100

>
> Med: Several PRRs are required to be deployed inside a service domain
realm. The current proposed solution does not assume a hierarchy between
these PRRs. But in some scenarios, two PRRs **may** intervene in the
delivery of connectivity services. These cascaded PRRs is required
because the involved parties are not managed by the same PRR. BTW, we
can imagine a hierarchy between PRRs, but this is solution specific and
should IMHO avoided in this slot.

Med: What your are describing can be supported, but this is not
recommended from an operational perspective. Only one level of PRRs is
required. Solutions should be easier and simple to manage. O&M should be
taken into account. Having this hierarchy may introduce some complexity.
I believe this is solution oriented discussion, and if required, should
be covered at the solution space preso.

Med: IPv4-inferred IPv6 prefixes are assigned to end-users. The enclosed
IPv4 addresses are shared between several customers. Only an IPv6
connectivity is offered. The core and the CPE/Home gateway/terminal are
IPv6-only. The interconnection between IPv6 and IPv4 realms are
stateless.

Med: This is a terminology issue: both CGN and port range are shared IP
address solutions.

Med: It is not a CGN flavor. It is a port range one.

what am i missing?

Med: Instead of enabling IPv4-in-IPv6 encapsulation to reach devices
sharing the same IPv4 address, all internal communications are
IPv6-only. Communications issued from IPv4 world are translated to IPv6.
The traffic is then routed, owing to IGP capabilities, to the device
among those having the same IPv4 address. Note that the shared IPv4
address is not used to send or to received traffic but it is used to
build an IPv4-inferred IPv6 prefix.  
Please refer to the draft for more information.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 20 Mar 2009 18:31:59 +0100

[email-masked] escribió:
> these PRRs.
right, i am not assuming it neither, i am just stating that it is possible

>  But in some scenarios, two PRRs **may** intervene in the

> be covered at the solution space preso.
maybe, imho, this is just to keep the scenario generic, as i said, it is 
not required, but possible

>> Med: Fine. The translation mode is not covered. See the following flow
>>     
> example:
>   
>>         +--+             +---+            +-----+               +--+
>>         |M1|             |CPE|            |i-PRR|               |RM|
>>         +--+             +---+            +-----+               +--+
>>           |                |                 |                    |
> connectivity is offered.

right, this is what is provided in use case 3
>  The core and the CPE/Home gateway/terminal are
> IPv6-only.

this is why i think this is a CGN use case rahter than a shara use case

>  The interconnection between IPv6 and IPv4 realms are
> stateless.
>
>   
this seems to be solution space to me

> Med: This is a terminology issue: both CGN and port range are shared IP
if, the only difference between CGN and port range is a terminology one, 
i am afraid i fail to see the point of this work

> Med: It is not a CGN flavor. It is a port range one.
i guess we simply disagree here

> Please refer to the draft for more information.
right, but you achieve all this by moving the NAT deeper into the network.

regards, marcelo

---

From: <[email-masked]>
Date: Fri, 20 Mar 2009 19:15:35 +0100

I'm confused with your explanation.

What is a CGN for you?

Cheers
Med

-----Message d'origine-----
De : marcelo bagnulo braun [mailto:[email-masked]] 
Envoyé : vendredi 20 mars 2009 18:32
À : BOUCADAIR Mohamed RD-CORE-CAE
Cc : [email-masked]
Objet : Re: [shara] First draft of the shara use cases for review

[email-masked] escribió:
> realm. The current proposed solution does not assume a hierarchy 
> between these PRRs.

>  But in some scenarios, two PRRs **may** intervene in the delivery of 
> connectivity services. These cascaded PRRs is required because the 
> involved parties are not managed by the same PRR. BTW, we can imagine 
> a hierarchy between PRRs, but this is solution specific and should 
> IMHO avoided in this slot.
>   

> PRR2 which gets IP1 and PR2 from PRR1, so that PR2 is included in PR1. 
> I understnad that all approaches support this, so that i why i thought 
> required. Solutions should be easier and simple to manage. O&M should 
> be taken into account. Having this hierarchy may introduce some complexity.
> I believe this is solution oriented discussion, and if required, 
> should be covered at the solution space preso.
>
>   
maybe, imho, this is just to keep the scenario generic, as i said, it is not required, but possible

> the v4 v6 translator is located deeper into the ISP network. Now, i 
> fail to see how this fits in the shara case, since i guess this would 
> be the CGN variation of the v4 v6 translator, rather than the share 
> variations, if you see what i mean.
>

>  The core and the CPE/Home gateway/terminal are IPv6-only.

>  The interconnection between IPv6 and IPv4 realms are stateless.
>
>   

> Med: This is a terminology issue: both CGN and port range are shared 
> IP address solutions.
>
>   
if, the only difference between CGN and port range is a terminology one, i am afraid i fail to see the point of this work

> What you depict in the figure seems the CGN flavor, i.e. the 
> translator is far from the client, so i would assume this is not 
> partof the shara effort.
>
>

regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 20 Mar 2009 19:22:26 +0100

> I'm confused with your explanation.
section 2.1.1. of draft-arkko-townsley-coexistence-00