Subject: [nat66] enterprise applications of IPv6/NAT

From: james woodyatt <[email-masked]>
Date: Mon, 6 Apr 2009 11:07:51 -0700

everyone--

I've opened an internal discussion with some people in Apple IS&T  
about the subject of NAT for IPv6.

I can relay their insistence, like those we've heard from other  
enterprise network operators via Fred Baker and others, that some kind  
of NAT is essential to Apple IS&T's IPv6 transition planning.  Despite  
their long experience with operating the 17/8 class A network, and the  
fact that ARIN has now assigned Apple some PI-space, 2620:0:1b00::/45,  
Apple IS&T expects to be operating NAT gateways for IPv6 in the future  
just like they do today with IPv4 for private B2B networks.

The latest message I received concluded with these paragraphs:
>
> In summary, I agree that your proposal will work, if both B2B  
> partners agree to advertise their FC00:: routes to each other via  
> the private link.  But there is some risk to the business from the  
> additional routes in the route table.  Also some extra complexity  
> from the additional static configuration (enabling use of the fc00::  
> subnet on the host, and possibly the fc00::/7 -> route if that can't  
> be put in a router advertisement).
>
> I don't consider the operational impacts to achieve "no IPv6 NAT  
> purity" worth it.  IPv6 to IPv6 NAT is an important tool in the  
> network engineer's toolbox.

I'm still trying to gain a detailed understanding of why they view the  
solutions in RFC 4864 as insufficient to meet their needs.  However,  
their reasons for preferring NAT are subtle and not at all what I  
expected.

The discourse has been enlightening so far, but I'm still not  
confident I can accurately represent the views of Apple IS&T on this  
list yet.  I'm still crawling up the learning curve, trying to  
understand their real concerns, and they're very busy people.  Getting  
them to explain Enterprise Network Operations 101 to me has to happen  
in their spare free time, and in mine, but I hope to have a more  
coherent report soon.

In the meantime, please be patient with me.  Thank you.

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: Keith Moore <[email-masked]>
Date: Tue, 07 Apr 2009 15:18:36 -0400

james woodyatt wrote:

>> In summary, I agree that your proposal will work, if both B2B partners
>> agree to advertise their FC00:: routes to each other via the private
>> link.  But there is some risk to the business from the additional
>> routes in the route table.  Also some extra complexity from the
>> additional static configuration (enabling use of the fc00:: subnet on
>> the host, and possibly the fc00::/7 -> route if that can't be put in a
>> router advertisement).

Just curious - assuming that ULAs should be used at all (and it's not
immediately clear that they should), why wouldn't an RA containing the
ULA prefix suffice to enable use of the subnet on each host?

To me it seems like more problems are likely to result from use of ULAs
as secondary prefixes, than from use of PA or PI global addresses.  In
particular, applications have to know whether to use a ULA or P* address
as a source and/or destination address, and default address selection
rules don't always do the right thing.  So you might have to statically
configure each app (because the "right thing" will vary from one app to
the next) but not each host.

>> network engineer's toolbox.

Reading this, it's difficult to not be reminded of Maslow's hammer that
makes everything look like a nail.

Still, it's important to understand this case better.  Either we need to
address it in an update to RFC 4864, or we need to make sure that IPv6
NAT satisfies this case.  (or maybe both, on the assumption that there's
too much mindshare behind NAT to expect network engineers to give it up
as a condition of IPv6 transition.... but we can hope that they'll learn
eventually to do without it.)

Keith

---

From: james woodyatt <[email-masked]>
Date: Tue, 7 Apr 2009 13:01:00 -0700

On Apr 7, 2009, at 12:18, Keith Moore wrote:
>>> partners

I'm still trying to socialize the idea that router advertisements may  
carry prefix information options with the A bit cleared and that this  
will signal hosts not to auto-configure any addresses with the prefix.

I'm expecting this fact to land in persistent memory at some point so  
it will not need any further repetition.  Cross your fingers with me.

> the next) but not each host.

As I wrote to you privately, I'm not sure I see why they feel the need  
to use ULAs at all.  It might just be that they read draft-baker-v6ops- 
b2b-private-routing, and now they're assuming that's Fred's way is the  
best current practice.  I'm trying to find out.

> makes everything look like a nail.

I prefer to think that when all you have is a hammer, then everything  
begins to look like a trombone player.

> eventually to do without it.)

I'm trying to pry a better description of this use-case out of the  
experts with whom I have some contact.  I recommend that others on  
this list who have similar contacts begin availing themselves now.  We  
need to figure out what these people are doing that has all these  
equipment vendors spinning up to sell them NAT66 boxes whether IETF  
standardizes it or not.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 08 Apr 2009 09:48:34 +1200

On 2009-04-08 08:01, james woodyatt wrote:

> As I wrote to you privately, I'm not sure I see why they feel the need to use ULAs at all.

Let me hazard a guess. They have great confidence that ULA prefixes will
never be accidentally advertised by ISPs, even if they are accidentally
leaked by careless site IT departments. Therefore, they are intrinsically
safer to use in intranet and extranet routing tables than any other form
of global scope prefix. This argument applies even if you don't entirely
trust the IT departments of your extranet partners.

Note, the global scope property is important. It's the only reasonable
scope for an extranet.

I don't think you'll find this way of thinking easy to change, any more
than you will persuade physical site security people to leave some of
the doors unlocked on the weekend.

   Brian

---

From: Keith Moore <[email-masked]>
Date: Tue, 07 Apr 2009 18:05:22 -0400

> trust the IT departments of your extranet partners.

Let me see if I understand you:

- Enterprises might like to be able to exchange traffic between some set
of hosts on their internal networks, and some set of external hosts.
For this reason (among others) it's a good idea if the addresses used on
the internal network have global scope.

- Such enterprises will of course expect to filter traffic between those
internal hosts, and non-approved external hosts, at their borders.
However, such filters might be misconfigured without anyone realizing
it.  And it might also be the case that traffic leaks out via unapproved
paths.

- Given the above, using ULAs appears to provide some additional
insurance against unauthorized traffic, because the enterprise networks
trust the ISPs to not advertise ULAs.

I can't fault the motivation.  But if I understand things right, I have
to wonder if the confidence that the enterprise network operators have
in ISPs to not route their ULAs is misplaced, or needs calibration.  It
seems to be tantamount to saying "we don't trust ourselves to maintain
accurate filters at our network borders, but we trust ISPs (including
those with whom we have no relationship) to maintain accurate BGP filters."

i.e. Things might well work the way the enterprise network operators
want them to, most of the time, but they're depending on unpaid allies
to provide security for them.

A better strategy might be to have a solid procedure in place for
maintaining and continuously testing those filters - as well as testing
the devices that watch for unauthorized traffic.  Of course, that
strategy wouldn't preclude use of ULAs.  But a decision to use ULAs
needs to be made in light of its effect on applications, and I have to
wonder how much analysis is being done there by the network operators.
(granted, it's not easy to do.)

> Note, the global scope property is important. It's the only reasonable

agreed.

> the doors unlocked on the weekend.

Sure, but a better analogy might be one of physical site security people
insisting on using red colored keys for internal doors, because they
think that nobody will lose, give away, or copy a key that is red.

Keith

---

From: james woodyatt <[email-masked]>
Date: Tue, 7 Apr 2009 15:51:14 -0700

everyone---

Okay, the Apple IS&T argument for wanting to use ULA and not PI for  
B2B extranet communication goes like this:

   + we expect to have public-facing servers at PI addresses;

   + some services at these servers still need to be reachable
     over the public Internet from B2B partner hosts;

   + those hosts may also be authorized separately to use the
     extranet link for access to other services at these servers;

   + some services on these servers may need to be reachable
     separately over either path, as named;

   + if we inject routes to our PI space to our partner networks,
     then *all* the traffic from partner hosts to our public-
     facing servers goes over the B2B extranet, not just that for
     specific services.  We don't want that.

Summarizing.  When partner hosts connect to server.apple.com at  
2620:0:1b00::SERVER, the traffic should go over the public Internet.   
When those same partner hosts connect to server.apple.com.b2b- 
extranet.example.com at $ULA::SERVER, the traffic should go over the  
private link.  Likewise, we need the same to happen when our hosts  
communicate with server.example.com and server.example.com.b2b- 
extranet.apple.com at the corresponding PI/PA and ULA addresses.

Quoting my IS&T contact again:
>
> I believe our 3 choices are:
>
> 1) Inject PI address into partner (and vice versa)
> 2) Inject ULA address into partner (and vice versa)
> 3) NAT at the partner connection
>
> #1 is broken because the hosts might need to talk to other partner/ 
> Apple services via another path
> #2 is dangerous because it dramatically increases the routing table  
> size.
> #3 does break end-to-end IPsec AH.  (not a large impact from my  
> standpoint)

What I infer that he means by "2) inject ULA address into partner (and  
vice versa)" is this: route ULA prefixes alongside PI prefixes  
throughout the enterprise to every network where B2B servers exist  
(potentially anywhere/everywhere) and aggregate those together into  
one or more ULA /48 prefixes to be injected into the partner network.

They'd prefer to conserve router table space, by routing only the PI- 
space addresses throughout the enterprise, then apply some kind of  
symmetric IPv6 NAT at the B2B extranet gateways.  They *do* care that  
IPsec AH is broken by this, and it *does* bother them that  
applications need to be NAT-friendly to work over the extranet link,  
but their calculation is that they're much more worried about  
conserving the router table space than they are about making  
application protocols jump through NAT hoops.

Whenever an enterprise router upsets because its table memory exhausts  
on an update, it can take out a whole building.  That tends to be very  
painful for the IS&T staff.  They're *VERY* sensitive to such risks.

This is why it doesn't help to use PI or PA space on the extranet  
instead of a ULA claim.  Either way, we still have the same load on  
the routing tables, but the former means consuming twice as much  
global space.  Also, it's worth noting that using PA space instead of  
ULA space means having to renumber the extranets when changing  
providers.  Using a symmetric IPv6 NAT avoids all that in one fell  
(and I do mean fell) swoop: interior routing tables are minimal in  
size because they only carry our PI/PA routes, *and* the B2B extranet  
addressing is independent of the PI/PA space addressing for the public- 
facing services.

I don't think there's anything in RFC 4864 to address this perception  
of address translation.  It's not really a "local network protection"  
method, is it?  It's a "local operational risk mitigation" method.

Now, it occurs to me that enterprise routers and interior routing  
protocols could be optimized for carrying a dual aggregation around at  
the same or near the same cost in router table space as operating a  
singularly aggregated routing domain, but I don't think we've tried to  
do that.  Have we?

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 08 Apr 2009 15:02:54 +1200

On 2009-04-08 10:51, james woodyatt wrote:
...
>> #1 is broken because the hosts might need to talk to other
>> partner/Apple services via another path
>> #2 is dangerous because it dramatically increases the routing table size.

I think this is FUD. I'd like to understand why it would be
'dramatic'. If you have N business partners that you reach by
ULAs, that would add at most N routes. That seems highly unlikely
to be dramatic.

If you actually want to funnel your business partner traffic
through a single firewall router, it could be that the only routes
you would add would be FC00::/7 and a more specific /48 for
your own in-house ULA prefix.

(Of course, there's no doubt that if you're running multiple prefixes,
according to the IPv6 standard model, your IGP will have to carry
multiple routes accordingly. But that's another discussion.)

    Brian

---

From: james woodyatt <[email-masked]>
Date: Wed, 8 Apr 2009 08:22:40 -0700

On Apr 7, 2009, at 20:02, Brian E Carpenter wrote:
> On 2009-04-08 10:51, james woodyatt wrote:...
> 'dramatic'. [...]
> (Of course, there's no doubt that if you're running multiple  
> prefixes, according to the IPv6 standard model, your IGP will have  
> to carry multiple routes accordingly. But that's another discussion.)

As I mentioned later in the same message, I think that's the "dramatic  
increase" they're talking about and it seems to be the core issue for  
them.

In my reply, I wrote this:
>
> Keep in mind that #3 breaks more than just IPsec authenticated header.
>
> It also breaks all applications that do referrals by address instead  
> of by name.  These aren't very common in IPv4, because of the  
> ubiquity of NAT deployments today, but you have to expect they will  
> be *much* more common in IPv6, where there will be far fewer, if  
> any, NAT deployments hindering address referrals.
>
> If you choose not to deploy sufficient routing capacity to carry  
> both the PI/PA and the ULA routes throughout Apple, then you're  
> making the cost of upgrading all of Apple's enterprise routers into  
> the barrier against deploying the very first application to come  
> along that requires address referrals to work over the B2B extranet  
> just like they already do on the public Internet.  Do you know what  
> application that might turn out to be?  I don't, but I hope for your  
> sake that it isn't something business-critical, with an impossible  
> deadline from senior executives, implying the need to roll out  
> service overnight at ULAs to every site in the Apple network.

I'm awaiting a response.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 10 Apr 2009 09:07:41 +1200

On 2009-04-09 03:22, james woodyatt wrote:
> increase" they're talking about and it seems to be the core issue for them.

Oh, I missed that, too many messages.

Well, I believe that IT managers will need to get over that concern.
If you're running 2 or 3 prefixes instead of the traditional 1, that
will (other things being equal) increase your IGP table size by a factor
2 or 3. I think it's a bit dramatic to call that 'dramatic', except
for sites large enough to have a PI prefix anyway, which makes the
problem go away without needing multiple prefixes. The whole complex
of problems we're discussing really only arises for sites too small to
get a PI prefix, and it's hard to imagine them being short of space for
their IGP tables.

>> of by name.  These aren't very common in IPv4, because of the ubiquity
>> of NAT deployments today, but you have to expect they will be *much*
>> more common in IPv6, where there will be far fewer, if any, NAT
>> deployments hindering address referrals.
>>
>> If you choose not to deploy sufficient routing capacity to carry both
>> the PI/PA and the ULA routes throughout Apple, then you're making the
>> cost of upgrading all of Apple's enterprise routers into the barrier
>> against deploying the very first application to come along that
>> requires address referrals to work over the B2B extranet just like
>> they already do on the public Internet.  Do you know what application
>> that might turn out to be?  I don't, but I hope for your sake that it
>> isn't something business-critical, with an impossible deadline from
>> senior executives, implying the need to roll out service overnight at
>> ULAs to every site in the Apple network.
> 
> I'm awaiting a response.

Let us know ;-)

   Brian

---

From: james woodyatt <[email-masked]>
Date: Thu, 9 Apr 2009 14:53:29 -0700

On Apr 9, 2009, at 14:07, Brian E Carpenter wrote:
>>> prefixes,
> [...] Well, I believe that IT managers will need to get over that  
> concern. [...]

I told them that IETF will likely try to address that concern by  
saying something along the lines of... Buy Enough Hardware To Meet  
Your Needs.  My contact called that a "vendor-centric" view of the  
world, and they proceeded to explain to me how that wasn't a realistic  
way to look at their issues.

That was before I elaborated my point about NAT breaking address  
referrals for applications that otherwise might be using them quite  
successfully on the public Internet now that IPv6 has sufficient  
address space to support them.  I am, however, not optimistic that I  
have changed their minds yet-- it's much harder to quantify the risk  
of investing in an infrastructure that makes tomorrow's applications  
prohibitively expensive and locks the company into using today's  
applications long past their expiration date.  The other side of that  
risk, i.e. over-investing in gear that we won't need if tomorrow's  
applications never arrive, has very tangible numbers stamped on it.

> [...] except for sites large enough to have a PI prefix anyway,  
> which makes the problem go away without needing multiple prefixes.   
> The whole complex of problems we're discussing really only arises  
> for sites too small to get a PI prefix, and it's hard to imagine  
> them being short of space for their IGP tables.

Actually, a PI prefix doesn't make the problem go away.  Apple has a  
PI prefix now: 2620:0:1b00::/45, and our IS&T managers are *still*  
planning to deploy IPv6/NAT boxes to facilitate separation of traffic  
for public-facing services and B2B extranet services.

Furthermore, now is probably a good time to note what my IS&T contact  
told me about NAT66's constraint of /48 for the maximum prefix length  
for the NAT range: it's unacceptably short, and they're insisting that  
vendors need to have an IPv6/NAT solution that operates with prefixes  
up to /64 at minimum.  I'm given to understand that official  
communications to that effect have already been sent to several  
vendors, but I have not seen them.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 10 Apr 2009 11:50:08 +1200

On 2009-04-10 09:53, james woodyatt wrote:
...

> Actually, a PI prefix doesn't make the problem go away.  Apple has a PI
> prefix now: 2620:0:1b00::/45, and our IS&T managers are *still* planning
> to deploy IPv6/NAT boxes to facilitate separation of traffic for
> public-facing services and B2B extranet services.

Sigh. It defeats me why people believe this will create less
admin work and less likelihood of errors than a set of ACLs
in the border routers.

> vendors need to have an IPv6/NAT solution that operates with prefixes up
> to /64 at minimum.  I'm given to understand that official communications
> to that effect have already been sent to several vendors, but I have not
> seen them.

I fully agree that /64 is needed. The IPv6 addressing architecture
really leaves no choice on that.

   Brian

---

From: james woodyatt <[email-masked]>
Date: Thu, 9 Apr 2009 17:28:59 -0700

On Apr 9, 2009, at 16:50, Brian E Carpenter wrote:
>> Actually, a PI prefix doesn't make the problem go away.  Apple has  
>> a PI prefix now: 2620:0:1b00::/45, and our IS&T managers are  
>> *still* planning to deploy IPv6/NAT boxes to facilitate separation  
>> of traffic for public-facing services and B2B extranet services.
>
> Sigh. It defeats me why people believe this will create less admin  
> work and less likelihood of errors than a set of ACLs in the border  
> routers.

It's the multiple prefixes thing, of course.  That, and the ongoing  
related worries, perhaps not entirely rational, about possible  
unexpected side effects of default address selection.  They think  
having just one set of prefixes to route through the enterprise will  
be a lot simpler and much less prone to administrative error.  I  
can't, of course, argue about that-- I simply don't know.

>> [...] about NAT66's constraint of /48 for the maximum prefix length  
>> for the NAT range: it's unacceptably short, and they're insisting  
>> that vendors need to have an IPv6/NAT solution that operates with  
>> prefixes up to /64 at minimum.  [...]
>

There was also some grousing when I mentioned that we don't think  
address amplification is a worthy goal for any new 6AI standards  
effort.  They've grown quite accustomed to using asymmetric  
translation to conserve address space in various parts of their  
network, and they're worried that its lacking in NAT66 will be a  
source of additional headache for them.

They really like their NAPT gateways, and the thought of planning to  
go without them into combat leaves them far, far away from their happy  
comfort zone.  I wish I knew how to soothe their nerves.

---

From: Keith Moore <[email-masked]>
Date: Thu, 09 Apr 2009 21:14:24 -0400

james woodyatt wrote:
> unexpected side effects of default address selection.  They think having
> just one set of prefixes to route through the enterprise will be a lot
> simpler and much less prone to administrative error.  I can't, of
> course, argue about that-- I simply don't know.

FWIW, I share their concerns about unexpected side effects of default
address selection.

OTOH, NATting everything still doesn't force B2B traffic to go through a
particular path for any app that does referrals across different realms.
 The app will use whatever external address it knows about in the
referral, which might or might not be the right address to use for any
particular peer.

I continue to believe that if a host has multiple addresses (for
whatever reason) then things work best if the application can learn that
it has multiple addresses at which it can be reached, and multiple
addresses from which it can source traffic, and it knows what they are.
 Trying to hide these things from the apps is a big part of what breaks
them, and it certainly makes it more difficult to fix the apps to work
under those conditions.

> effort.  They've grown quite accustomed to using asymmetric translation
> to conserve address space in various parts of their network, and they're
> worried that its lacking in NAT66 will be a source of additional
> headache for them.

I suspect it does mean that network operators have to manage addresses
subtly differently than they have in the past.   E.g. instead of trying
to build a deep hierarchy of address allocation/delegation, they might
find it works better to make the delegation hierarchy shallow.  The good
news is that even if you only have a /48, you can still address 2**16
LANs, give each of them a /64, and put as many hosts on each of those
LANs as you can stand, without running out of addresses on any of those
LANs.  (and if you have more than 2**16 LANs you ought to be able to get
at least another /48 if not a shorter prefix).

> They really like their NAPT gateways, and the thought of planning to go
> without them into combat leaves them far, far away from their happy

I keep telling people that IPv6 is a lot more different than IPv4 than
they think.  A lot of the conventional wisdom from IPv4 doesn't apply.
But it's hard to get people to see that, and I think it will take a few
years of actual experience before network operators in general start to
get it.

Keith

---

From: Rémi Després <[email-masked]>
Date: Fri, 10 Apr 2009 11:12:17 +0200

Keith Moore  -  le (m/j/a) 4/10/09 3:14 AM:

> whatever reason) then things work best if the application can learn
> that it has multiple addresses at which it can be reached, and
> multiple addresses from which it can source traffic, and it knows
> what they are. Trying to hide these things from the apps is a big
> part of what breaks them, and it certainly makes it more difficult to
> fix the apps to work under those conditions.

I agree that applications should _be able_ to know about their possibly
multiple addresses.
But I also believe that SCTP and SHIM6 should work with several local
addresses, without applications having to be aware of it.

> I suspect it does mean that network operators have to manage
> addresses subtly differently than they have in the past.   E.g.
> instead of trying to build a deep hierarchy of address
> allocation/delegation, they might find it works better to make the
> delegation hierarchy shallow.  The good news is that even if you only
> have a /48, you can still address 2**16 LANs, give each of them a
> /64, and put as many hosts on each of those LANs as you can stand,
> without running out of addresses on any of those LANs.  (and if you
> have more than 2**16 LANs you ought to be able to get at least
> another /48 if not a shorter prefix).

Many personal computers can establish LANs behind them, and/or can run
several internal virtual machines (what I call "host-rooted subnets").

Let's assume such a host is on a /64 link, with a /128 address.

If a bridge function in the host is not possible (e.g. because of a
different LAN standard behind the host) or  not desirable (e.g. for
multicast isolation), then some sort of NAPT66 is the most
straightforward solution so far for hosts behind the host to have IPv6
outgoing connectivity.

>> They really like their NAPT gateways, and the thought of planning
>> to go without them into combat leaves them far, far away from their
>> happy comfort zone.  I wish I knew how to soothe their nerves.

Draft-despres-sam-02 presents a general approach that, for hosts that
can be modified, eliminates the need to use  NAPT66s and restores e2e
transparency.

Soothing these people's nerves is likely to take time, but less if we
make the necessary steps in the necessary direction.

> I keep telling people that IPv6 is a lot more different than IPv4
> than they think.  A lot of the conventional wisdom from IPv4 doesn't
> apply. But it's hard to get people to see that, and I think it will
> take a few years of actual experience before network operators in
> general start to get it.

In my understanding, the essential difference is  that with 128-bit
addresses it is possible to assign _global addresses to all hosts_, even
at the leafs of a long hierarchy of independently administered routing
zones.  E2e transparency, and simple referrals, which were part of the
initial Internet model can thus be restored.

If done right, traversal of private-addressing realms can be supported,
as well as multihoming at various points of the routing hierarchy.

To really take advantage of 128-bit addresses, the work in IMHO _not
finished_: some constraints that  are stronger than needed in many
useful configurations need to be relaxed (very carefully indeed, but
relaxed).

Among them, we have:
- /48s to all customer sites (easily relaxed)
- 64-bit IIDs in all global unicast addresses (less easily relaxed, but
IMHO with a great potential).

I hope that the number of reactions to the current SAM proposal will 
increase(www.ietf.org/internet-drafts/draft-despres-sam-02): it's the 
result of a significant effort to tackle this subject with a global view.

Regards,

RD

---

From: Gert Doering <[email-masked]>
Date: Fri, 10 Apr 2009 14:46:37 +0200

Hi,

> Let's assume such a host is on a /64 link, with a /128 address.

For this sort of scenario, I see two ways to solve it:

 - DHCP prefix delegation
   (this host is acting as a router, so it should be a proper router, and
    DHCP PD is a very sane way to get a new prefix for "clients")

 - N:1 NAPT66

all other stuff, like "setting up tunnels all over the place" is going to
drive up complexity in insane ways.  Who is supposed to troubleshoot all
the tunneling mess?

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  128645

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 11 Apr 2009 08:41:58 +1200

On 2009-04-10 21:12, Rémi Després wrote:
...
> Let's assume such a host is on a /64 link, with a /128 address.

What a depressing assumption.

Why not assume it's on a /64 link but has been assigned 16 /128 addresses?

   Brian

---

From: Rémi Després <[email-masked]>
Date: Mon, 13 Apr 2009 10:34:03 +0200

> Why not assume it's on a /64 link but has been assigned 16 /128 addresses?

The idea is that a typical default behavior consists in taking as IID
the modified EUI-64 that is derived from the unique MAC address
available on the link.

But, yes, other assumptions are possible. The CPE, and intermediate
routers if there are some, can indeed use prefix-delegation. This is
however, IMHO, not as typical and simple.

Prefix delegation, which has its own applicability scope, seems to me
somewhat opposed to that of SLAAC. More intermediates solutions seem
possible. SAM is thought to be a starting point for this, but I am
conscious that this still needs to be clarified.

RD

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 15 Apr 2009 14:43:50 +1200

I wasn't exactly thinking of prefix delegation. I meant what I said
literally: assign N addresses to a subscriber, where N doesn't have
to be a power of 2 and the addresses don't have to be contiguous.
The CPE can either hand them out to LAN hosts, or statelessly
NAT66 them. Either way, we don't mess with the /64 boundary,
and the SOHO can have a large handful of addresses.

    Brian