DHCPv6 Prefix Delegation in Long-Term Evolution (LTE) Networks
draft-sarikaya-v6ops-prefix-delegation-11

Hi,

I have been assigned the task of reviewing this document and make a recommendation for the IESG. This review is a process and IETF & IANA end-run check only, not a technical review. See http://tools.ietf.org/html/rfc5742 for more information.

My overall recommendation is the following:

  2. The IESG has concluded that this work is related to IETF work done
      in the V6OPS, 6MAN, and DHC WGs, but this relationship does not prevent publishing.

I have Cced the relevant working group chairs in case they have an opinion. I have also Cced Atle since this draft refers to 3GPP work. Nevertheless, the draft quite correctly states:

  The techniques described in this document have not been approved
  either by the IETF or by 3GPP, except what is described below in
  Section 3.3.  This document is not a standard or best current
  practice.  This document is published only as a possibility for
  consideration by operators.

I do have some technical comments, however. These are provided as-is, in case they are helpful to you authors or the RFC Editor:

The document would benefit from a statement early on, saying that it is useful when address space needs to be managed by DHCP-PD. There are obviously other means of managing address space, including having the AR track internally what address space is used by what mobile.


>    MN may next request additional /64 prefixes from the AR using DHCPv6
>    prefix delegation where MN is the requesting router and AR is the
>    delegating router [RFC6459], Section 5.3.1.2.6 in [ThreeGPP23401].
>    In this case the call flow is similar to Figure 3.  Solicit message
>    must include the IA_PD option with prefix-length field set to 64.  MN
>    may request more than one /64 prefixes.  AR as delegating router must
>    delegate these prefixes excluding the prefix assigned to the default
>    connection.

I do not understand why you limit the MN to request address space in /64 chunks. If I'm a mobile router I may want a /56 and then use that in the way that I want.

>    AR should broadcast the prefix(es) dynamically upstream as the route
>    information of all the MNs connected to this AR.  In point-to-point
>    links, this causes high routing protocol traffic (IGP, OSPF, etc.)
>    due to Per-MN interface prefixes.  To solve the problem, route
>    aggregation should be used.  For example, each AR can be assigned a
>    /48 or /32 prefix (aggregate prefix, aka service provider common
>    prefix) while each interface of MN can be assigned a /64 prefix.  The
>    /64 prefix is an extension of /48 one, for example, an AR's /48
>    prefix is 2001:DB8:0::/48, an interface of MN is assigned 2001:DB8:0:
>    2::/64 prefix.  The AR only broadcasts it's /48 or /32 prefix
>    information to Internet.

First off, there are two ways of doing this. One is to use static configuration, which I think would  be preferable in many cases. No routing protocols needed, because each AR has a known piece of address space. If the DHCP servers know this space, too, then they will assign from that space to a particular AR.

If the other method, routing protocols, are used then aggregation is OK, of course. But you do not explain above how the aggregation happens. Is this just the manual configuration, or do you expect the AR-DHCP server somehow automatically arrive at the desired aggregation? In any case, the AR is an AS-internal device and only participates in the IGP. As a result, the AR does not broadcast anything to the Internet.

>
>    This policy can be enforced as follows: DHCP Relay must set the IPv6
>    Prefix field in IA_PD Prefix option in IA_PD option in the Relay
>    Forward message to the aggregate prefix (/48, /32, or /16 prefix
>    assigned to the AR).

I don't understand how this works. Does DHCP-PD support prefix assignment from a given shorter prefix? That's news to me, at least. I re-read RFC 3633 Section 10 and I did not see this functionality there.

Jari

The draft draft-sarikaya-v6ops-prefix-delegation-10
is ready for publication from the Independent Stream.
Please ask IESG to review it, as set out in RFC 5742.

The following is some background for this draft, please forward it
to IESG along with this request ...

The draft's title is "DHCPv6 Prefix Delegation in Long Term Evolution
(LTE) Networks," it's abstract includes this sentence:
"Based on the idea that DHCPv6 servers can manage prefixes, we address
prefix management issues such as the access router offloading delegation
and release tasks of the prefixes to a DHCPv6 server using DHCPv6 Prefix
Delegation."

This draft was presented and discussed in v6ops, but did not attract
enough interest to become a WG item. Fred Baker (v6ops co-chair)
suggested they make it an Independent Submission.

The draft includes a 'disclaimer' paragraph (last in section 1)
pointing out that "The techniques described in this document have not
been approved either by the IETF or by 3GPP."

Thanks, Nevil (ISE)

--
Nevil Brownlee (ISE), rfc-ise@rfc-editor.org