Subject: [v4v6interim] Dynamic Host Configuration Protocol (DHCP) Options for Port Restricted IP Address Assignment

From: <[email-masked]>
Date: Fri, 26 Sep 2008 09:48:24 +0300

Hi,

A draft draft-bajko-v6ops-port-restricted-ipaddr-assign-00.txt should be
soon available in I-D tracker, but meanwhile you can get it from here:
http://www.kotiposti.net/tsavo/draft-bajko-v6ops-port-restricted-ipaddr-
assign-00.txt

Abstract 
    
   This document defines two Dynamic Host Configuration Protocol for 
   IPv4 [RFC2131] options that allow servers to assign port restricted 
   IPv4 addresses to clients. Port restriction may be necessary in 
   cases when one public IPv4 address is assigned to multiple clients 
   because of scarcity of the available IPv4 addresses.  

Comments are welcome.

Best regards,

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

---

From: Lars Eggert <[email-masked]>
Date: Fri, 26 Sep 2008 10:14:14 +0300

Hi,

I don't quite get why this document is targeted at v6ops - this is  
proposing to change how IPv4 transport stacks behave in a very  
significant way and absolutely needs to be discussed in the transport  
area due to its effects (port randomization interactions, some apps  
requiring a specific source port, etc.)

It's also not clear to me whether the restriction to point-to-point  
links means that the clients access link needs to be a point-to-point  
link or if the intent is that point-to-point link must extend end-to- 
end?

Lars

---

From: Lars Eggert <[email-masked]>
Date: Fri, 26 Sep 2008 10:17:39 +0300

Pressed "send" too quickly.

I meant to add that a regular NAT is also inherently more efficient at  
multiplexing many clients onto a set of external IP addresses, because  
the mapping is done on-demand, whereas this approach assigns chunks of  
ports to clients which they may never fully utilize (every client is  
obviously going to ask for a bit more than all the ports it may ever  
need).

Also, note that you're not only limiting how many connections a client  
have open concurrently, you're also creating a limit on the connection  
establishment rate, due to TIMEWAIT.

Lars

On 2008-9-26, at 10:14, Lars Eggert wrote:

> significant way and absolutely needs to be discussed in the  
> transport area due to its effects (port randomization interactions,  
> some apps requiring a specific source port, etc.)
>
> links means that the clients access link needs to be a point-to- 
> point link or if the intent is that point-to-point link must extend  
> end-to-end?
>
> Lars
>

---

From: Jari Arkko <[email-masked]>
Date: Fri, 26 Sep 2008 13:52:01 +0300

This is interesting. As Lars pointed out, this is more in the scope of 
the interim, int/tsv areas, and behave than v6ops.

In any case, I find it hard to comment in too much detail about the bit 
level details in DHCP before we've agreed upon on what the architectural 
directions for the solutions will be (e.g., are fractional addresses a 
reasonable approach?). A couple of comments anyway:

If this information is carried in DHCP, how do you ensure that it is not 
accidentally used outside the p2p link model?

The server and the tunnel endpoint implementations have to be bound 
together very tightly.

I found the implications on sending packets to your own address but to a 
different port number range mind boggling.

Given the way the options have been defined, I'm not sure if you can 
deploy this except in greenfield networks. I think ability to fall back 
to a carrier-side NAT and a full but private IP address is a 
requirement. But according to Section 3.2 the server just grants you a 
fraction, and if the client does not understand that, we have no 
connectivity. I suspect there's an another way to define the extensions 
without this problem.

Jari

---

From: Mark Townsley <[email-masked]>
Date: Fri, 26 Sep 2008 13:11:26 +0200

I agree that using DHCP, ABPB, or whichever protocol (SIP anyone? IPsec 
mode-config? PPP IPCP?) is secondary to the question of introducing 
fractional addressing in general. I have a suspicion that if we go down 
this road, we'll see the control aspects handled in more than one way.

- Mark

Jari Arkko wrote:
> In any case, I find it hard to comment in too much detail about the 
> bit level details in DHCP before we've agreed upon on what the 
> architectural directions for the solutions will be (e.g., are 
> fractional addresses a reasonable approach?). A couple of comments 
> anyway:
>
> If this information is carried in DHCP, how do you ensure that it is 
> not accidentally used outside the p2p link model?
>
> I found the implications on sending packets to your own address but to 
> a different port number range mind boggling.
>
> deploy this except in greenfield networks. I think ability to fall 
> back to a carrier-side NAT and a full but private IP address is a 
> connectivity. I suspect there's an another way to define the 
> extensions without this problem.
>
> Jari
>

---

From: <[email-masked]>
Date: Fri, 26 Sep 2008 18:22:13 +0300

Hi, 

>-----Original Message-----
>From: ext Jari Arkko [mailto:[email-masked]] 
>Sent: 26 September, 2008 13:52
>To: Savolainen Teemu (Nokia-D-MSW/Tampere)
>Cc: [email-masked]
>Subject: Re: [v4v6interim] Dynamic Host Configuration Protocol 
>(DHCP) Options for Port Restricted IP Address Assignment
>
>This is interesting. As Lars pointed out, this is more in the 
>scope of the interim, int/tsv areas, and behave than v6ops.

We can change that.

>In any case, I find it hard to comment in too much detail 
>about the bit level details in DHCP before we've agreed upon 
>on what the architectural directions for the solutions will be 
>(e.g., are fractional addresses a reasonable approach?). A 
>couple of comments anyway:

I'm very much looking forward for clear advances in architectural
decisions in the interim, so that we could start to progress fast on
solutions. This contribution aims to bring fractional address concept
more concrete - and hopefully easier to think about.

>If this information is carried in DHCP, how do you ensure that 
>it is not accidentally used outside the p2p link model?
>The server and the tunnel endpoint implementations have to be 
>bound together very tightly.

We'll look more into that, but it surely depends on network where
fractional IP addresses are deployed - I don't expect them to be
deployed everywhere, but on those scenarios where seen feasible/useful.
In some networks I can easily imagine server and point-to-point link
endpoints being in the same device.

>I found the implications on sending packets to your own 
>address but to a different port number range mind boggling.

Doesn't this easily happen in distributed NAT case if a GW is given a
port range, and the host A behind GW is sending packet to a host B under
different GW, that happens to have been allocated same address but
another part of the same IP's port range:

                 one frac addr          one public addr
                    +----+                   +---+  +-------------+
   IPv4 host A -----+ GW +======tunnel=======+CGN+--+IPv4 Internet|
                    +----+                   |   |  +-------------+
                                             |   |
            same frac addr, different pool   |   |
                    +----+                   |   |
   IPv4 host B -----| GW |======tunnel=======|   |
                    +----+                   +---+
   <---private v4--->            NAT               <----public v4--->
                            (distributed,
                            over a tunnels (or p2p links

>Given the way the options have been defined, I'm not sure if 
>you can deploy this except in greenfield networks. I think 

Is it a problem? Actually this is a general question I have: shall we
limit ourselves to solutions that can be deployed to old networks as
well (for same of implementation & deployment simplicity and to cut down
number of solutions), or can we have both: solutions that work in old
networks and better solutions that work only in greenfield networks? I
guess this is one topic for next week's discussions.

>ability to fall back to a carrier-side NAT and a full but 
>private IP address is a requirement. But according to Section 
>3.2 the server just grants you a fraction, and if the client 
>does not understand that, we have no connectivity. I suspect 
>there's an another way to define the extensions without this problem.

The server should allocate a fractional IP address only if it's pool of
full IPv4 addresses is becoming low enough. Whether server assigns
fractional address always to hosts indicating support for such, or only
when full IPv4 pool becomes low enough, is in my opinion
implementation/network management issue. The case where server assigns
fractional address for host not indicating support should not occur
(otherwise pool of addresses is too small for that network).

Best regards and thank you for your comments,

	Teemu

---

From: Jari Arkko <[email-masked]>
Date: Fri, 26 Sep 2008 19:05:58 +0300

Teemu,

> We can change that.

No, keep your file name. Our comments were mainly directed at where this 
should be discussed.

> guess this is one topic for next week's discussions.

I'm not sure I personally have a strong opinion about the requirement 
for either model. But the engineer in me felt that there might be ways 
to make this more deployable, e.g., give frac addrs to those devices 
that can handle them and real ones or private addresses for the rest.

Jari

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 26 Sep 2008 14:37:48 -0700

...
> requirement. But according to Section 3.2 the server just grants you
> a fraction, and if the client does not understand that, we have no

Address Plus Port (A+P),
https://mice.cs.columbia.edu/getTechreport.php?techreportID=560 has considered
this problem, and it suggests having
the subscriber NAT include a new DHCP option that indicates the NAT
understands how to NAT to a restricted port range.  If the new DHCP
option is not in the DHCP request, the ISP's router knows the
subscriber has a "legacy" NAT, and the ISP's router will need to
ensure that subscriber's traffic is NATted by an ISP's NAT.  The
relevant text in A+P is at the top of page 4:

    >
    >  2. An A+P gateway should include some option in the DHCP
    >     request message, to inform the PE router of its
    >     abilities. (Constraint 2)
    >  3. If no A+P signaling was done, the PE router should
    >     perform NATting, including whatever ALG functions it
    >     can. (Constraints 3 and 4)
    >  4. The PE router should leave intact any packets from the
    >     proper address and port range. (Constraints 4 and 5)
    >
    >    Note that a customerwith no NAT or with a non-A+PNAT may
    >    emit packets within the proper port range by accident,
    >    thus accidentally violating part of point 4 above. We
    >    solve that by DHCP-based signaling from the A+P box: the
    >    A+P option in the DHCP request tells the PE that a
    >    customerprovided box will do all NATting according to
    >    this design. In that case, the primary function of the
    >    PE router is to enforce restrictions on port numbers in
    >    outbound packets.
    >

-d

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 29 Sep 2008 11:36:05 +0100

On 26 sep 2008, at 7:48, <[email-masked]> <[email-masked] 
 > wrote:

> Comments are welcome.

Although slicing an IPv4 address into pieces by port range could be  
useful, I think this is more trouble than it's worth, because any  
protocol that needs a "full" IPv4 address to function is going to  
break. This includes ARP. Now you can of course define this to be only  
used on networks that don't have ARP, but I still think it's too  
dangerous.

A solution that allows an application to reserve a port for incoming  
traffic (and maybe use that port for outgoing traffic as well) through  
NAT would be closer to current practice and not nearly as dangerous.  
Would be nice if this could also work for IPv6 in the case of some  
form of NAT-PT or without NAT but just a firewall.
_______________________________________________
v4v6interim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v4v6interim

---

From: Rémi Després <[email-masked]>
Date: Mon, 29 Sep 2008 13:44:42 +0200

Iljitsch van Beijnum   (m/j/a) 9/29/08 12:36 PM:
> On 26 sep 2008, at 7:48, <[email-masked]> 
> <[email-masked]> wrote:
> 
> protocol that needs a "full" IPv4 address to function is going to break. 
> This includes ARP. Now you can of course define this to be only used on 
> networks that don't have ARP, but I still think it's too dangerous.

In the SAM proposal of 
http://www.ietf.org/internet-drafts/draft-despres-sam-scenarios-00.txt, 
port restricted IPv4 packets are encapsulated in local addressing packets.
ARP works as usual on encapsulating packets.

I will present it in Montreal (APBP-Revised item of the agenda).

Regards.

RD