Subject: [shara] Shara scope

From: <[email-masked]>
Date: Mon, 26 Jan 2009 13:45:06 +0100

Hi,

So, shara deals with "port range" and softwire deals with DS-lite, which
is fine with me, even if all IPv4 shared address solutions in the same
WG would also make sense.

But what about other solutions? I'm thinking of CGN in its Double NAT
version. It is a solution already deployed in some ISPs' networks and
the only one currently available on shelves (even if DS-lite
implementations make quick progress).

Shouldn't we integrate a BCP document in the "Proposed Work" section to
cover this item? Basically considerations of where to locate the CGN and
how to route the traffic between customers and CGN?

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

---

From: Olaf Maennel <[email-masked]>
Date: Mon, 26 Jan 2009 17:13:52 +0200

> WG would also make sense.

well, i'm a bit confused, ...as i think there is significant overlap.

> how to route the traffic between customers and CGN?

yes.  but i don't think we will be able to restrict where to locate the CGN.
"all we could do" with port range efforts is to keep the end-customer in
control over its own fate (with regards to the translation of course)...

    olaf

---

From: <[email-masked]>
Date: Tue, 27 Jan 2009 08:23:55 +0100

Hi,

And behave works with NATs.. I would think NAT, CGN, or multiple instances are not to be part of this work item as such, as those are already handled elsewhere?

What is not done elsewhere is the "port range" and its implications to protocols, networks, hosts, and applications.

What could be also discussed to some extent is port restricted IP address integration to some already existing solutions. For example DHCP-based port restricted IP address allocation mechanism could be used as DS-Lite extension, but also as stand-alone feature on point-to-point links. Also other address assignment methods, like MIP, could be extended with port restricted IP address allocation support.

Whatever mechanism to allocate these addresses is used, there are some common problems like how multiplexing/routing is to be done, blind attacks, protocols not having ports, fragmentation etc.

One approach could be to define here the concept of port restricted addresses and sort out the generic problems, and maybe define the DHCP extension as one mechanism, and leave the adoption of the concept to other technologies to be done in corresponding working groups.

Best regards,

    Teemu

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext [email-masked]
Sent: 26 January, 2009 14:45
To: [email-masked]
Subject: [shara] Shara scope

Hi,

So, shara deals with "port range" and softwire deals with DS-lite, which is fine with me, even if all IPv4 shared address solutions in the same WG would also make sense.

But what about other solutions? I'm thinking of CGN in its Double NAT version. It is a solution already deployed in some ISPs' networks and the only one currently available on shelves (even if DS-lite implementations make quick progress).

Shouldn't we integrate a BCP document in the "Proposed Work" section to cover this item? Basically considerations of where to locate the CGN and how to route the traffic between customers and CGN?

Pierre

---

From: Olaf Maennel <[email-masked]>
Date: Tue, 27 Jan 2009 10:42:25 +0200

Hi, 

Teemu, i completely agree with your definition of the scope. we tried in our
draft to separate the functionality of NAT and port-range.  ...and i think
its possible to cleanly separate those two functions.

However, there is an interconnection point. because port-range proposals
will need NATs, when connecting legacy devices. As we don't expect that all
end-devices will be upgradable (okay, your phones will be - but hosts behind
them not necessarily). So there must be some NATing involved somewhere, and
actually i believe this could be designed in a really flexible manner. For
example in your mobile setting: (1) laptop behind the phone could do it
NATing itself (and only send "port-range packets"), (2) the mobile phone
could do the NATing, or (3) the base station ??, or (4) the NATing could be
done somewhere in the providers network (a la cgn's).
All we have to do in port-range is to signal where NATing is possible. Which
i believe would be the connection point with behave...

Cheers, 

    olaf

On 27/01/09 9:23 AM, "[email-masked]"
<[email-masked]> wrote:
> Hi,
> 
> And behave works with NATs.. I would think NAT, CGN, or multiple instances are
> not to be part of this work item as such, as those are already handled
> elsewhere?
> 
> What is not done elsewhere is the "port range" and its implications to
> protocols, networks, hosts, and applications.
> 
> What could be also discussed to some extent is port restricted IP address
> integration to some already existing solutions. For example DHCP-based port
> restricted IP address allocation mechanism could be used as DS-Lite extension,
> but also as stand-alone feature on point-to-point links. Also other address
> assignment methods, like MIP, could be extended with port restricted IP
> address allocation support.
> 
> Whatever mechanism to allocate these addresses is used, there are some common
> problems like how multiplexing/routing is to be done, blind attacks, protocols
> not having ports, fragmentation etc.
> 
> One approach could be to define here the concept of port restricted addresses
> and sort out the generic problems, and maybe define the DHCP extension as one
> mechanism, and leave the adoption of the concept to other technologies to be
> done in corresponding working groups.
> 
> Best regards,
> 
>     Teemu
> 
> So, shara deals with "port range" and softwire deals with DS-lite, which is
> fine with me, even if all IPv4 shared address solutions in the same WG would
> also make sense.
> 
> But what about other solutions? I'm thinking of CGN in its Double NAT version.
> It is a solution already deployed in some ISPs' networks and the only one
> currently available on shelves (even if DS-lite implementations make quick
> progress).
> 
> Shouldn't we integrate a BCP document in the "Proposed Work" section to cover
> this item? Basically considerations of where to locate the CGN and how to
> route the traffic between customers and CGN?
> 
> 
> 
> Pierre

---

From: <[email-masked]>
Date: Wed, 28 Jan 2009 21:03:31 +0100

Hi,

I ment that there's no need to work here about how NATs work (or how those are traversed) in general, but indeed the coexistence with NATs and placement of NAT are of interest.

While new phones could be containing support for this feature, the old ones definitely would not. Thus the gateway serving large number of terminals would need to provide public IPv4 address or NAT for some while letting others use shared addresses. And this distribution would likely change as legacy devices would go away and new ones come in, and even more so when IPv6 becomes common.

About the signaling. On the DHCP-based solutions, I think (at least in our proposal solution) the signaling could work by node sending in DHCPDISCOVER indication of its support for shared addresses, and with that it would implicitly indicate no need for NATting by the delegating host (if it indeed delegates shared addresses). On the chain of delegating nodes the first node that does not indicate support for shared addresses in its DHCPDISCOVER essentially indicates to the node above to provide private IPv4 address and instantiate NAT.

Best regards,

        Teemu

>-----Original Message-----
>From: ext Olaf Maennel [mailto:[email-masked]]
>Sent: 27 January, 2009 10:42
>To: Savolainen Teemu (Nokia-D-MSW/Tampere)
>Cc: [email-masked]
>Subject: Re: [shara] Shara scope
>
>
>Hi,
>
>Teemu, i completely agree with your definition of the scope.
>we tried in our draft to separate the functionality of NAT and
>port-range.  ...and i think its possible to cleanly separate
>those two functions.
>
>However, there is an interconnection point. because port-range
>proposals will need NATs, when connecting legacy devices. As
>we don't expect that all end-devices will be upgradable (okay,
>your phones will be - but hosts behind them not necessarily).
>So there must be some NATing involved somewhere, and actually
>i believe this could be designed in a really flexible manner.
>For example in your mobile setting: (1) laptop behind the
>phone could do it NATing itself (and only send "port-range
>packets"), (2) the mobile phone could do the NATing, or (3)
>the base station ??, or (4) the NATing could be done somewhere
>in the providers network (a la cgn's).
>All we have to do in port-range is to signal where NATing is
>possible. Which i believe would be the connection point with behave...
>
>Cheers,
>
>    olaf
>
>
>> And behave works with NATs.. I would think NAT, CGN, or multiple
>> instances are not to be part of this work item as such, as those are
>> already handled elsewhere?
>>
>> What could be also discussed to some extent is port restricted IP
>> address integration to some already existing solutions. For example
>> DHCP-based port restricted IP address allocation mechanism could be
>> used as DS-Lite extension, but also as stand-alone feature on
>> point-to-point links. Also other address assignment methods,
>like MIP,
>> could be extended with port restricted IP address allocation support.
>>
>> Whatever mechanism to allocate these addresses is used,
>there are some
>> common problems like how multiplexing/routing is to be done, blind
>> attacks, protocols not having ports, fragmentation etc.
>>
>> One approach could be to define here the concept of port restricted
>> addresses and sort out the generic problems, and maybe
>define the DHCP
>> extension as one mechanism, and leave the adoption of the concept to
>> other technologies to be done in corresponding working groups.
>>
>> Best regards,
>>
>>     Teemu
>>
>> From: [email-masked] [mailto:[email-masked]]
>On Behalf
>> Of ext [email-masked]
>> So, shara deals with "port range" and softwire deals with DS-lite,
>> which is fine with me, even if all IPv4 shared address solutions in
>> the same WG would also make sense.
>>
>> It is a solution already deployed in some ISPs' networks and
>the only
>> one currently available on shelves (even if DS-lite implementations
>> make quick progress).
>>
>> Shouldn't we integrate a BCP document in the "Proposed Work" section
>> to cover this item? Basically considerations of where to locate the
>> CGN and how to route the traffic between customers and CGN?
>>
>>
>>
>> Pierre

---

From: Olaf Maennel <[email-masked]>
Date: Thu, 29 Jan 2009 00:38:58 +0200

Hi, 

On 28/01/09 10:03 PM, "[email-masked]"
<[email-masked]> wrote:
> Hi,
> 
> I ment that there's no need to work here about how NATs work (or how those are
> traversed) in general, but indeed the coexistence with NATs and placement of
> NAT are of interest.
> 
> While new phones could be containing support for this feature, the old ones
> definitely would not. Thus the gateway serving large number of terminals would
> need to provide public IPv4 address or NAT for some while letting others use
> shared addresses. And this distribution would likely change as legacy devices
> would go away and new ones come in, and even more so when IPv6 becomes common.

if i recall correctly, Alain said something very similar... just he wasn't
talking about phones. :)
 
> About the signaling. On the DHCP-based solutions, I think (at least in our
> proposal solution) the signaling could work by node sending in DHCPDISCOVER
> indication of its support for shared addresses, and with that it would
> implicitly indicate no need for NATting by the delegating host (if it indeed
> delegates shared addresses).

just an initial list of bullet-points what needs to be signaled. (I think
its identical with what you said...):

- a set of public IPv4 addresses,
- for each IPv4 address the allocated port-range,
- the tunneling technology to be used
  (e.g., "in-IPv6-encapsulation", or in your case that you have layer-2)
- addresses of the tunnel endpoints (e.g., IPv6 address of tunnel endpoints)
- whether or not NAT functionality is provided by the gateway

anything missing besides a version number and some reserved bits for future
use? :)

> On the chain of delegating nodes the first node
> that does not indicate support for shared addresses in its DHCPDISCOVER
> essentially indicates to the node above to provide private IPv4 address and
> instantiate NAT.

agreed. 

    olaf