Subject: clarifications regarding RFC3314/3177

From: "JORDI PALET MARTINEZ" <[email-masked]>
Date: Sat, 11 Sep 2004 14:54:09 +0200

Hi all,

This email is mainly addressed to the authors of RFC3314, and somehow to RFC3177.

During the last APNIC meeting, a week ago, we had some interesting discussions regarding the RFC3177 recommendation of /48 for sites (even SOHO) and what it seems a contradiction with 3GPP recommendations, which seem confusing for APNIC (and seems also for other RIRs) and consequently are creating some troubles when accepting allocation requests from customers in order to apply the policy in a wise way.

This happens probably because the lack of expertise in 3GPP, so inputs from 3GPP experts will be very helpful.

I copy here Miwa (from APNIC) questions and also provide below my own view, which may be wrong, so we are looking

> RFC 3314       Recommendations for IPv6 in 3GPP Standards September 2002
> 
> <snip>
> 2.3 Assigning a Prefix to Only One Primary PDP Context
> 
>   The IPv6 WG recommends that the 3GPP treat a primary PDP context,
>   along with its secondary PDP contexts, as a single IPv6 link, and
>   that the GGSN view each primary PDP context as a single subnet.
>        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>   Accordingly, a given global (or site-local) prefix should not be
>   assigned to more than one PDP context.
> 
>   Because multiple IPv6 hosts may attach through a 3GPP handset, the
>   IPv6 WG recommends that one or more /64 prefixes should be assigned
>                           ^^^^^^^^^^^^^^^^^^^^^^^^
>   to each primary PDP context.  This will allow sufficient address
>   space for a 3GPP-attached node to allocate privacy addresses and/or
>   route to a multi-link subnet [MULTLINK], and will discourage the use
>   of NAT within 3GPP-attached devices.
> <snip>
> 
> I have two questions about the above expression "one or more /64
> prefixes should be assigned to each primary PDP context."
> 
> Q1:  I understood by reading this RFC that GPRS handset is not a single
> subnet device by design and "the GGSN view each primary PDP context as a
> single subnet" so a MT may have multiple subnets .  Based on this
> understanding, I wonder if this recommendation implicate a /48
> assignment per a MT by saying "one or more /64 prefixes"?

My view is that providing a /64 for PDP context (every possible subnet MT as I understand) is enough. What is not clear is that such several possible /64 should be grouped in a single /48 (for aggregation purposes), considering that the number of active PDP context for every MT is not know in advance. Obviously, reserving a /48 will mean a lot of (may be) not necessary addressing space, and will mean that the block allocated for the ISP providing such service will need to be much much much bigger that actually used. I'm in favor of aggregation and balancing network management versus address space (which seems to be big enough to do so), but I wonder if a 3GPP device has capabilities to handle 65.535 /64 (from a single /48), and thus if this is rational from a policy perspective.

Of course, I also understand that a 3GPP device acting as router for a network (for example a mobile network), could need several /64 (though not sure if a /48), for different subnets (interfaces ?). But is not in this case every subnet being routed to a different PDP context ?.

> 
> Now the second question.
> 
> RFC 3177, IAB/IESG Recommendations on IPv6 Address Allocations to Sites
> stated: <snip>
> 
>      -  Mobile networks, such as vehicles or mobile phones with an
>         additional network interface (such as bluetooth or 802.11b)
>         should receive a static /64 prefix to allow the connection of
>         multiple devices through one subnet.
> <snip>
> 
> Q2: Should I read RFC3314 as a new recommendation that presents a
> different view from the RFC 3177? 
> 

I think the point is here what I replied in my 2nd paragraph to the previous question, because a mobile network, if has a single interface, can provide connectivity with a single /64. If the mobile router has several interfaces, I understand each one will use a different PDP context, and thus receive a new /64 ?.

The point otherwise is if we have the case where a SOHO is connected using a 3GPP router, which I guess then should receive by default a /48. But then we come back to the question of easy management of the network, as in advance we may not know how many customer will use just a terminal or a mobile router.

Regards,
Jordi

PS: Please copy Miwa in the reply as I'm not sure she is actually in this mail exploder

**********************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on line at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 13 Sep 2004 14:22:07 +0200

Jordi,

As you imply, "one or more /64 prefixes" is in fact completely compatible
with "/64 or /48". As one of the culprits behind RFC 3177, I still
believe that once a subscriber needs to subnet, everything will be
much easier if the next step up is *always* a /48. Imagine the mess if
you give 3 adjacent /64s to one subscriber and 7 to the next, etc.
So I read the "more" case in RFC 3314 as invoking the /48
prefix case in RFC 3177. That is certainly the advice I would give
a 3G operator. Just keep things simple.

However, please remember that 3177 was only a recommendation to the
RIRs. It isn't the law. The RIRs developed their policy after
taking a lot of input, not just 3177.

    Brian