Subject: [dhcwg] DHCPv6 Proxy Agent

From: Joseph Hyunwook Cha <[email-masked]>
Date: Tue, 04 Nov 2008 01:40:33 +0000 (GMT)

Hello, folks.

I would like to introduce DHCPv6 proxy agent in a saparate thread. 
The following is a rough description regarding the DHCPv6 proxy agent. 
Any comments will be appreciated.

1. Motivation
Under the environments where classic bridge technology can not be applicable, local hosts on the link connected to the ND proxy [RFC4389] can be easily configured with global addresses through SLAAC.
   However, if the service provider provides DHCPv6 service for the internet connectivity of customer's hosts and is willing to give only /128 addresses without delegating prefixes, there are no other feasible solutions than 6to6 NAPT for of local hosts to share the Internet connection. To address this problem, new element called DHCPv6 proxy agent is suggested, which supports message transactions between hosts in the LAN and remote server in the provider network using IAID demultiplexing. 

2. Behavior Description of DHCPv6 proxy agent
                 
                           DHCPv6 
                          Proxy Agent                      
            |             +-------+                +--------+
    local |Ethernet  |           | Wireless  | Access |
            +---------+    A     +-)))   (((-+              +--> rest of network
   hosts |              |           |     link     | Point     |
            |              +-------+               +--------+
                            ND Proxy 
                      
   DHCPv6 proxy agent is devised to proxy DHCPv6 clients on the LAN side links of the agent. In order to achieve this goal, the proxy agent joins to the All_DHCP_Relay_Agents_and_Servers (FF02::1:2) mulicast group with the LAN interface and listen for DHCP messages on UDP port 547.   
   When an RA message indicating DHCPv6 service for addresses with M flag set to 1, the ND proxy advertises proxyed RA message derived from the received one to the LAN. When the proxyed RA message is received at a local host, the host invokes DHCPv6 client if the host has DHCPv6 client installed. 
   Then, a solicit message sent by the local host is processed by the proxy agent as following. 
   Firstly, it checks with DUID and transcation ID if the solicit message is arrived for the first time. 
   If so, it creates new proxy transaction for proxing the solicit message, which comprise the following elements. 
   - original transaction related information (IAID, IA-type, DUID, transaction ID) from the received message.
   - proxy transaction related information (proxy IAID, proxy DUID, proxy transaction ID).
   - expire time.    
   For the new proxy transaction, the agent generates new transaction ID and chooses a IAID value from pre-configured proxy IAID pool by its policy. 
   If the solicit message includes multiple IAIDs, the agent should choose same number of proxy IAID values as original IAIDs. 

   The proxy DUID is the DUID of the agent which is supposed to be same for all proxy transactions, which is not a requirement. 
   The expire time is the time until the proxy transaction is valid and calculated from MAX timeout value for each type of message as is specified in RFC3315 5.5. 
   For example, expire time for the proxyed solicit message is current time plus 120 seconds(SOL_MAX_RT) plus some marginal delay. 
   After creating the new proxy transaction, the agent generates new proxy solicit message by substituting IAID, DUID and transaction ID in the original message with proxy IAID, proxy DUID and proxy transaction ID respectively. 
and sends it through the upstream interface (Wireless link from the above illustration).    
   If a retransmitted message sent by the local host is arrived at the proxy agent, proxy message is generated using existing proxy transaction and expire time is recalculated by the above rule.
   When a reply message for a proxied message is received at the upstream interface of the proxy agent, 
relevant proxy transaction is searched by comparing DUID in the client ID option and transaction ID in the message with proxy DUID and proxy transaction ID in existing transactions. 
If the match proxy transaction is found, the agent generates new proxy reply message by substituting IAID, DUID and transaction ID in the original message with proxy IAID, proxy DUID and proxy transaction ID respectively. 
and sends it through the LAN interface. If no match proxy transaction is found, reply message is silently ignored. 
   If a binding information is conveyed in the received Reply message, the agent also populates or refreshes the coresponding proxy binding using the match proxy transaction, which comprises the following elements. 
   - original binding related information (IAID, IA-type, DUID) 
   - proxy binding related information (proxy IAID, proxy DUID, server DUID, IA address and valid lifetime, ...)
   The proxy binding is required since the agent should initiate a proxy transaction for Confirm message in case that the upstream interace might be moved to different link, and also be able to forward messages initiated by the server or the proxy agent to the local hosts. 

Joseph

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

---

From: Ted Lemon <[email-masked]>
Date: Mon, 3 Nov 2008 21:24:00 -0700

On Nov 3, 2008, at 6:40 PM, Joseph Hyunwook Cha wrote:
>   However, if the service provider provides DHCPv6 service for the  
> internet connectivity of customer's hosts and is willing to give  
> only /128 addresses without delegating prefixes, there are no other  
> feasible solutions than 6to6 NAPT for of local hosts to share the  
> Internet connection. To address this problem, new element called  
> DHCPv6 proxy agent is suggested, which supports message transactions  
> between hosts in the LAN and remote server in the provider network  
> using IAID demultiplexing.

I don't see how this would help.   If the provider is only willing to  
provide a /128, what makes you think that (a) the routing will work  
for more than one /128, and (b) that the provider will be willing to  
give you a second or subsequent /128 after you've acquired the first?

Also, why do you need to define additional protocol to make this  
happen?   It seems to me that you can already do this by using  
multiple IAIDs, so there's no need for an additional draft.

Personally, I think that if ISPs in general start giving out /128s, we  
have pretty much wasted the effort of creating IPv6, because we'll  
effectively have an IPv4 network, only with substantially bigger  
protocol headers.

---

From: Mark Smith <[email-masked]>
Date: Sat, 8 Nov 2008 23:28:49 +1030

On Mon, 3 Nov 2008 21:24:00 -0700
Ted Lemon <[email-masked]> wrote:

Hi Ted,

> > using IAID demultiplexing.
<snip> 
> effectively have an IPv4 network, only with substantially bigger  

I think the market will sort that out pretty quickly. If an ISP chooses
only to give out /128s, then another ISP can use the huge amount and
low cost IPv6 address space they have to create a competitive advantage
over the first ISP.

I'm not sure about other parts of the world, but ISPs down here in .au
are well aware that their customers are typically connecting multiple
devices behind NAT, because the ISPs themselves are selling NAPT enabled
by default ADSL routers to their customers. If they're offering VoIP
services, they're also probably quite aware of the problems NAT
creates. I think there is a chance that they'll be more open to the
idea of customers having multiple public addresses or subnets once the
address space itself is cheap and plentiful.

Regards,
Mark.