Subject: Re: [homenet] homenet-prefix-assignment update - prefix length 64 and on prefix comparison

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 08 Oct 2014 12:09:38 +0200

Hi Pierre,

Thanks for the draft update.  Now I have two questions:

> prefixes of size 64 are RECOMMENDED.

Why is this length recommended?  I think it may be because of Ethernet?

Maybe it would be advantageous to not make any recommendation on the 
prefix length.  Some times this may develop into a barrier beyond which 
it will be hard to go.

The other question is about the assumed capability to decide non between 
prefixes, such as to detect collisions.  Do you think it is possible to 
decide equality between prefixes?  I rather think prefixes have a more 
refined relationship than just equal/not-equal - e.g. they are also 
aggregated.

If Router1 advertises P1/64 and Router2 P2/65 aggregated in P1 do you 
think a 'collision' could be detected?  I doubt we have such an 
algorithm somewhere.

Alex

Le 30/06/2014 17:18, Pierre Pfister a écrit :
> Hello group,
>
> I’d like to inform you about the changes made in the two last homenet-prefix-assignment updates.
>
> http://tools.ietf.org/html/draft-pfister-homenet-prefix-assignment-02
>
> The changes are mostly about fixing typos, but a few technical changes have been made as well (based on the experience gained from the implementation of the Prefix Assignment Algorithm over HNCP).
>
>
>   — Changes between 00 and 01
>
> - If a Delegated Prefix is included in another Delegated Prefix, it is ignored. This is intended to improve support for non-homenet routers that provide prefix sub-delegation. That way, sub-delegated prefixes are ignored.
>
> - Adding network leader definition (The router with the highest identifier).
>
> - Add a section about DHCPv6 downstream prefix delegation. For downstream RFC7084 routers support.
>
> - Adding Delegated Prefix deprecation procedure in order to differentiate prefix deprecation and node disconnection. When a node disconnect, the DPs advertised by this node may be kept some time (depending on the DP's lifetimes). But if a DP is actively deprecated, nodes must stop using it immediately.
>
>
>   — Changes between 01 and 02
>
> - Designated router election can make use of the information provided by the flooding protocol (i.e. when no router is designated yet, only the highest router id present on the link can become designated).
>
> - New implementation guideline in appendix concerning "prefix waste avoidance". It proposes an algorithm that provides a good trade-of between randomness, pseudo-randomness and prefix selection efficiency.
>
>
>
> Comments are welcome,
>
> Pierre Pfister
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet
>
>

---

From: Pierre Pfister <[email-masked]>
Date: Wed, 8 Oct 2014 13:28:37 +0200

Hi Alex,

Reply is inlined,

> Why is this length recommended?  I think it may be because of Ethernet?

I’m not a big fan of putting 64s everywhere neither. And I strongly disagree with mandating 64 bit long prefixes. 
The prefix algorithm itself is agnostic on this side.

Nevertheless, some parts of this document are home-network specific. 
Not even talking about crappy implementations, home network links should support SLAAC whenever possible.
Which is the reason why using 64bit long prefixes is RECOMMENDED.

But smaller prefixes are better than *no prefix at all*. 
When there are not enough prefixes available (e.g. the ISP provides a single 64 while we have multiple links), smaller prefixes can be used (80 for instance). 
Which means dhcpv6 must be used.
Our implementation supports it, and it works with my laptop.

But again, that should be avoided whenever possible. And ISPs MUST provided enough prefixes (IMO).

> 
> Maybe it would be advantageous to not make any recommendation on the prefix length.  Some times this may develop into a barrier beyond which it will be hard to go.
> 
> The other question is about the assumed capability to decide non between prefixes, such as to detect collisions.  Do you think it is possible to decide equality between prefixes?  I rather think prefixes have a more refined relationship than just equal/not-equal - e.g. they are also aggregated.
> 
> If Router1 advertises P1/64 and Router2 P2/65 aggregated in P1 do you think a 'collision' could be detected?  I doubt we have such an algorithm somewhere.
> 

Equality is never considered alone. Actually, most of the time, you will find considerations such as:
The prefix is not included or does not include any other Assigned
       Prefix with a higher precedence.

This is how collisions are detected.

Cheers,

- Pierre

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 08 Oct 2014 13:58:17 +0200

Hi Pierre,

Le 08/10/2014 13:28, Pierre Pfister a écrit :
> I’m not a big fan of putting 64s everywhere neither. And I strongly
> disagree with mandating 64 bit long prefixes. The prefix algorithm
> itself is agnostic on this side.
>
> Not even talking about crappy implementations, home network links
> should support SLAAC whenever possible. Which is the reason why using
> 64bit long prefixes is RECOMMENDED.

Ah, I see.  I doubt though SLAAC is 64.  Maybe Ethernet is.

> But smaller prefixes are better than *no prefix at all*. When there
> are not enough prefixes available (e.g. the ISP provides a single 64
> while we have multiple links), smaller prefixes can be used (80 for
> instance). Which means dhcpv6 must be used. Our implementation
> supports it, and it works with my laptop.

Ok.

> provided enough prefixes (IMO).

I agree with you.

Last time I checked Free ISP seems to provide 8 /64 prefixes to my homenet:
2001:db8:0:ce10::/64
2001:db8:0:ce11::/64
...
2001:db8:0:ce17::/64
I dont think these could be aggregated into a single shorter prefix, or 
my math is missing.

Second, their (Free's) web interface asks me to put a next hop for each 
of these prefixes.

Do you think HNCP implementation may help fill in these fields 
automatically somehow?

>> Maybe it would be advantageous to not make any recommendation on
>> the prefix length.  Some times this may develop into a barrier
>> beyond which it will be hard to go.
>>
>> The other question is about the assumed capability to decide non
>> between prefixes, such as to detect collisions.  Do you think it is
>> possible to decide equality between prefixes?  I rather think
>> prefixes have a more refined relationship than just equal/not-equal
>> - e.g. they are also aggregated.
>>
>> If Router1 advertises P1/64 and Router2 P2/65 aggregated in P1 do
>> you think a 'collision' could be detected?  I doubt we have such an
>> algorithm somewhere.
>>
>
> Equality is never considered alone. Actually, most of the time, you
> will find considerations such as: The prefix is not included or does
> not include any other Assigned Prefix with a higher precedence.

I wonder about the implementability of this statement, but yes it may be 
possible to write one.

> This is how collisions are detected.

Ok.

Alex

>>> http://tools.ietf.org/html/draft-pfister-homenet-prefix-assignment-02
The changes are mostly about fixing typos, but a few technical changes 
have been made as well (based on the experience gained from the 
implementation of the Prefix Assignment Algorithm over HNCP).
>>> - If a Delegated Prefix is included in another Delegated Prefix,
>>> it is ignored. This is intended to improve support for
>>> non-homenet routers that provide prefix sub-delegation. That way,
>>> sub-delegated prefixes are ignored.
>>>
>>> - Adding Delegated Prefix deprecation procedure in order to
>>> differentiate prefix deprecation and node disconnection. When a
>>> node disconnect, the DPs advertised by this node may be kept some
>>> time (depending on the DP's lifetimes). But if a DP is actively
>>> deprecated, nodes must stop using it immediately.
>>>
>>>
>>> - Designated router election can make use of the information
>>> provided by the flooding protocol (i.e. when no router is
>>> designated yet, only the highest router id present on the link
>>> can become designated).
>>>
>>> - New implementation guideline in appendix concerning "prefix
>>> waste avoidance". It proposes an algorithm that provides a good
>>> trade-of between randomness, pseudo-randomness and prefix
>>> selection efficiency.
>>>
>>>
>>>
>>> Comments are welcome,
>>>
>>> Pierre Pfister _______________________________________________
>>> homenet mailing list [email-masked]
>> _______________________________________________ homenet mailing
>> list [email-masked]

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 08 Oct 2014 14:13:22 +0200

Pierre, just a small doubt, but I agree with you in general.

Le 08/10/2014 13:58, Alexandru Petrescu a écrit :
[...]
>> not include any other Assigned Prefix with a higher precedence.

It is hard to say whether a prefix is included into another or not.  We 
do not have a published algorithm to say what it means for a prefix to 
include another.

In general, we have a common understanding (and not published algorithm) 
about what it means 'longest prefix match'.  But that compares an 
address to a prefix, not a prefix to a prefix.

Sure, one could assume that an address is just a /128 prefix and execute 
longest prefix match with it as if it were an address.

But then again which prefix has the role of the address and which is the 
role of the prefix?  In other words, when hearing two prefixes on a link 
and want to compare them, which of them should be compared against the 
other by using the longest-prefix match?  There are two possibilities 
and two different outputs for a particular tuple of prefixes, depending 
on the order of this longest prefix match.

Of course, I do not mention the easy case which compares two prefixes of 
precisely same length.

Just because the length is different may make think that the prefixes 
are different.  Or otherwise one could be aggregated into another.  But 
there are several types of aggregation: matching up to the shortest 
length, matching up to middle, up to longest length, beyond the longest 
length.

These cases are not documented and people may implement them in many 
different ways with different outputs when trying to tell whether this 
or that prefix are equal or included into one another.

Alex

---

From: Pierre Pfister <[email-masked]>
Date: Wed, 8 Oct 2014 14:15:48 +0200

> Ah, I see.  I doubt though SLAAC is 64.  Maybe Ethernet is.

SLAAC relies on ‘interface identifier’. Ethernet uses the EUI-64.
I have no knowledge of other methods of generating an interface identifier.

The why64 draft is interesting (and sad) on that front.

> I dont think these could be aggregated into a single shorter prefix, or my math is missing.

That is 2001:db8:0:ce10::/61

> 
> Second, their (Free's) web interface asks me to put a next hop for each of these prefixes.
> 
I’m not sure what that means. Is that in the freebox ?
I guess it doesn’t support DHCPv6-PD (yet). Could you check that ?

If you put a homenet router below your freebox, you will have to provide a prefix to the homenet router manually (which is supposed to be done by DHCPv6-PD).

> Do you think HNCP implementation may help fill in these fields automatically somehow?
> 
> 
> I wonder about the implementability of this statement, but yes it may be possible to write one.

I’ll reply to your other mail concerning that.

---

From: Pierre Pfister <[email-masked]>
Date: Wed, 8 Oct 2014 14:25:42 +0200

A prefix can only contain another prefix if its prefix length is smaller.

Here is some C-code that provides what you are looking for.

Cheers,

- Pierre

/* Tell whether a prefix contains an address */
uint8_t prefix_contains(const struct in6_addr *p, uint8_t plen, const struct in6_addr *addr)
{
	int blen = plen >> 3;
	if(blen && memcmp(p, addr, blen))
		return 0;

	int rem = plen & 0x07;
	if(rem && ((p->s6_addr[blen] ^ addr->s6_addr[blen]) >> (8 - rem)))
		return 0;

	return 1;
}

/* Tell whether a prefix contains another prefix */
uint8_t prefix_include(const struct in6_addr *p1, uint8_t plen1, const struct in6_addr *p2, uint8_t plen2)
{
	if(plen1 > plen2)
		return 0;
	
	return prefix_contains(p1, plen1, p2);
}

/* Tell whether two prefixes are colliding */
uint8_t prefix_collision(const struct in6_addr *p1, uint8_t plen1, const struct in6_addr *p2, uint8_t plen2)
{
	return prefix_include(p1, plen1, p2, plen2) || prefix_include(p2, plen2, p1, plen1);
}

Le 8 oct. 2014 à 14:13, Alexandru Petrescu <[email-masked]> a écrit :

> It is hard to say whether a prefix is included into another or not.  We do not have a published algorithm to say what it means for a prefix to include another.
> 
> In general, we have a common understanding (and not published algorithm) about what it means 'longest prefix match'.  But that compares an address to a prefix, not a prefix to a prefix.
> 
> Sure, one could assume that an address is just a /128 prefix and execute longest prefix match with it as if it were an address.
> 
> But then again which prefix has the role of the address and which is the role of the prefix?  In other words, when hearing two prefixes on a link and want to compare them, which of them should be compared against the other by using the longest-prefix match?  There are two possibilities and two different outputs for a particular tuple of prefixes, depending on the order of this longest prefix match.
> 
> Of course, I do not mention the easy case which compares two prefixes of precisely same length.
> 
> Just because the length is different may make think that the prefixes are different.  Or otherwise one could be aggregated into another.  But there are several types of aggregation: matching up to the shortest length, matching up to middle, up to longest length, beyond the longest length.
> 
> These cases are not documented and people may implement them in many different ways with different outputs when trying to tell whether this or that prefix are equal or included into one another.
> 
> Alex
> 
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 08 Oct 2014 14:29:39 +0200

Le 08/10/2014 14:15, Pierre Pfister a écrit :
>>> I’m not a big fan of putting 64s everywhere neither. And I
>>> strongly disagree with mandating 64 bit long prefixes. The prefix
>>> algorithm itself is agnostic on this side.
>>>
>>> Nevertheless, some parts of this document are home-network
>>> specific. Not even talking about crappy implementations, home
>>> network links should support SLAAC whenever possible. Which is
>>> the reason why using 64bit long prefixes is RECOMMENDED.
>>
> SLAAC relies on ‘interface identifier’. Ethernet uses the EUI-64. I
> have no knowledge of other methods of generating an interface
> identifier.
>
>>> But smaller prefixes are better than *no prefix at all*. When
>>> there are not enough prefixes available (e.g. the ISP provides a
>>> single 64 while we have multiple links), smaller prefixes can be
>>> used (80 for instance). Which means dhcpv6 must be used. Our
>>> implementation supports it, and it works with my laptop.
>>
>> Ok.
>>
>> Last time I checked Free ISP seems to provide 8 /64 prefixes to my
>> homenet: 2001:db8:0:ce10::/64 2001:db8:0:ce11::/64 ...
>> 2001:db8:0:ce17::/64 I dont think these could be aggregated into a
>> single shorter prefix, or my math is missing.
>

Right, sorry, my math was missing.  So I suppose Free ISP delegates a
single /61 to me then, not several /64s.  This is a local prefix
division performed in that router.  I do not necessarily agree with it,
as I could have divided it differently, or I could have announced the 
/61 in RA in the first link of the homenet, etc.

> I’m not sure what that means. Is that in the freebox ?

YEs, it is in the Freebox Server (not Player), the freebox OS 3.0, sorry 
no advertisement.

> I guess it doesn’t support DHCPv6-PD (yet). Could you check that ?

It does not support DHCPv6-PD Server on the ingress side, or otherwise 
these fields containing 'next-hop' would have not been there.

As DHCPv6-PD Client on the egress side - I dont know, no means to check 
unless I loose it.

> If you put a homenet router below your freebox, you will have to
> provide a prefix to the homenet router manually (which is supposed to
> be done by DHCPv6-PD).

Yes, I agree with  you.  No DHCP-PD at this time.

But if the freebox had a daemon listening to commands to fill in these 
next-hop fields then it would work.

I am saying this because I speculate the way in which this particular 
operator may work, but I have no affiliation with it.

Alex

>>>> Maybe it would be advantageous to not make any recommendation
>>>> on the prefix length.  Some times this may develop into a
>>>> barrier beyond which it will be hard to go.
>>>>
>>>> The other question is about the assumed capability to decide
>>>> non between prefixes, such as to detect collisions.  Do you
>>>> think it is possible to decide equality between prefixes?  I
>>>> rather think prefixes have a more refined relationship than
>>>> just equal/not-equal - e.g. they are also aggregated.
>>>>
>>>> If Router1 advertises P1/64 and Router2 P2/65 aggregated in P1
>>>> do you think a 'collision' could be detected?  I doubt we have
>>>> such an algorithm somewhere.
>>>>
>>>
>>> Equality is never considered alone. Actually, most of the time,
>>> you will find considerations such as: The prefix is not included
>>> or does not include any other Assigned Prefix with a higher
>>> precedence.
>>
>>>>> - If a Delegated Prefix is included in another Delegated
>>>>> Prefix, it is ignored. This is intended to improve support
>>>>> for non-homenet routers that provide prefix sub-delegation.
>>>>> That way, sub-delegated prefixes are ignored.
>>>>>
>>>>> differentiate prefix deprecation and node disconnection. When
>>>>> a node disconnect, the DPs advertised by this node may be
>>>>> kept some time (depending on the DP's lifetimes). But if a DP
>>>>> is actively deprecated, nodes must stop using it
>>>>> immediately.
>>>>>
>>>>>
>>>>> designated yet, only the highest router id present on the
>>>>> link can become designated).
>>>>>
>>>>> - New implementation guideline in appendix concerning
>>>>> "prefix waste avoidance". It proposes an algorithm that
>>>>> provides a good trade-of between randomness,
>>>>> pseudo-randomness and prefix selection efficiency.
>>>>>
>>>>>
>>>>>
>>>>> Comments are welcome,
>>>>>
>>>>> Pierre Pfister
>>>>> _______________________________________________ homenet
>>>>> mailing list [email-masked]
>>>> _______________________________________________ homenet
>>>> mailing list [email-masked]

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 8 Oct 2014 14:34:53 +0200 (CEST)

On Wed, 8 Oct 2014, Alexandru Petrescu wrote:

> as I could have divided it differently, or I could have announced the /61 in 
> RA in the first link of the homenet, etc.

Why on earth would you want to do that?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Ole Troan <[email-masked]>
Date: Wed, 8 Oct 2014 14:38:55 +0200

Pierre, Alex,

please make sure this document does comply with http://datatracker.ietf.org/doc/draft-ietf-6man-why64/
while I think the algorithm and data formats should support any prefix lengths, I don't think the sections dealing with "what if we've run out of prefixes" should be included in this document.

cheers,
Ole

> On 08 Oct 2014, at 13:28 , Pierre Pfister <[email-masked]> wrote:
> 
> Hi Alex,
> 
> Reply is inlined,
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 08 Oct 2014 14:51:34 +0200

> Why on earth would you want to do that?

divide differently? or /61 in RA?

Alex

---

From: Ted Lemon <[email-masked]>
Date: Wed, 8 Oct 2014 08:51:35 -0400

You guys are debating points that are long-since decided.

On Oct 8, 2014, at 8:29 AM, Alexandru Petrescu <[email-masked]> wrote:

> as I could have divided it differently, or I could have announced the /61 in RA in the first link of the homenet, etc.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 8 Oct 2014 14:55:26 +0200 (CEST)

> divide differently? or /61 in RA?

Divide at anything else than /64. A=1 in SLAAC doesn't work unless you're 
using /64 subnet size.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 08 Oct 2014 15:01:12 +0200

Le 08/10/2014 14:55, Mikael Abrahamsson a écrit :
> Divide at anything else than /64.

I meant a /61 can be divided in 8 /64s, or in 4 /64s plus 2 /63s, right? 
  There are some configuration advantages for the latter.

> A=1 in SLAAC doesn't work unless
> you're using /64 subnet size.

I didnt know that?  Can you elaborate?  Is it that I can not set radvd 
with A=1 and plen=63?  Or is it that the Host receiving this RA will not 
know what do with this RA?

Alex

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 8 Oct 2014 15:14:10 +0200 (CEST)

> know what do with this RA?

https://datatracker.ietf.org/doc/draft-ietf-6man-why64/?include_text=1

"As a result, RFC 4291 describes a method of forming interface
    identifiers from IEEE EUI-64 hardware addresses [IEEE802] and this
    specifies that such interface identifiers are 64 bits long."

If you set anything different than /64, then A=1 is meaningless and the 
host won't form SLAAC based addresses based on A=1.

---

From: Pierre Pfister <[email-masked]>
Date: Wed, 8 Oct 2014 15:14:49 +0200

Hi Ole,

I remember we were supposed to discuss that at last IETF. Well, let’s discuss it here now I guess.

First, that’s why the use of 64 long prefixes is recommended. And I think it could be a fairly good consensus.
draft-ietf-6man-why64 is a very interesting document. An informational one. Correct me if I’m wrong but I’m not sure it’s possible to ‘comply’ to an informational document.

In general, my opinion about this whole debate is that it’s not because it happens that some implementations are broken that we should make specifications brake on purpose as well.
On a user perspective, IPv6 is barely deployed. Don’t you think IPv6 implementations will get fixed if IETF stop telling them they are perfectly right to be broken ?

Our current implementation (http://www.homewrt.org) supports this backup scenario. And it works. And hosts obtain addresses using DHCPv6. And they receive RAs with prefix length which is not 64. And my Mac is fine, and linux laptops are fine too. I’d rather have a /80 than no connectivity at all.

Why should we mandate homenet implementations to *brake* in situations where they could work fine ? Why should we voluntarily prevent a link from being configured if we actually can configure it ?

If MUSTs are the solution, then I would rather see a ‘ISP MUST provide a /56 to customers’ than ‘Homenet MUST brake when the provided prefix is not big enough’.

Also, this scarcity avoidance mechanism is optional. If the vendor considers it as too complex. He can drop it. And brake.

Cheers,

- Pierre

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 08 Oct 2014 16:10:59 +0200

Le 08/10/2014 15:14, Pierre Pfister a écrit :
[...]
> Why should we mandate homenet implementations to *break* in
> situations where they could work fine ? Why should we voluntarily
> prevent a link from being configured if we actually can configure it
> ?

Sorry, there is no intention to tell networks where 64 works that 64
must not work.

There is however an intention to not say 64, and just say 'n'.

Old:
> Although that choice is completely implementation specific, prefixes
> of size 64 are RECOMMENDED.

New:
 > Although that choice is completely implementation specific,
 > implementations MUST support prefixes of arbitrary length.

Alex

---

From: Tim Chown <[email-masked]>
Date: Wed, 8 Oct 2014 15:21:38 +0100

> If MUSTs are the solution, then I would rather see a ‘ISP MUST provide a /56 to customers’ than ‘Homenet MUST brake when the provided prefix is not big enough’.

But this is what the homenet arch text says in Section 3.4.1:
http://tools.ietf.org/html/draft-ietf-homenet-arch-17#section-3.4.1

i.e. don’t go longer than /64, and ISPs should provide enough prefixes.

The why64 text is very relevant here.

Tim

---

From: Mark Townsley <[email-masked]>
Date: Wed, 8 Oct 2014 22:16:58 +0200

A homenet implementation may indeed decide to self-destruct in a puff of smoke before daring to step foot into the classful lowlands of the Interface ID, but I actually appreciate that the algorithm itself is more general; for robustness sake, in case it is ever used in a different context, in the event that why64 ends up being wrong, if ISPs don't listen to us and /64 becomes common and we have to do *something* to accommodate, etc. 

Don't get me wrong, I've fought long and hard in many forums and venues to keep ISPs from thinking /64 is ever a good idea. I have no problem with the strongest language we can provide to try and enforce that. At the same time, hedge your bets. 

- Mark

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 09 Oct 2014 13:35:17 +1300

> The why64 text is very relevant here.

And could be added as a reference. It's already in IESG Evaluation
(with one open issue that was just flagged).

Certainly the mechanisms should support any prefix length, but
the reality remains that only /64 subnets work properly in all
circumstances today.

    Brian

---

From: Mark Townsley <[email-masked]>
Date: Thu, 9 Oct 2014 07:25:30 +0200

> On Oct 9, 2014, at 2:35 AM, Brian E Carpenter <[email-masked]> wrote:
> 

Informative reference, as we don't want to create a downref over this.

> 
> Certainly the mechanisms should support any prefix length,

I agree.

- Mark

> but

---

From: Pierre Pfister <[email-masked]>
Date: Thu, 9 Oct 2014 11:26:56 +0200

Hello,

I’m proposing this change then.

1. In case the provided prefix is 64, the default consist in assigning prefixes of length 64 first.
2. I’m adding a reference to 6man-why64.

When the algorithm decides to make a new assignment, it first needs
   to specify the desired size of the assigned prefix.  Although this
   algorithm intends to remain generic, it was observed in
   [I-D.ietf-6man-why64] that hosts may malfunction when the prefix
   length is not 64.  Therefore, prefixes of length 64 are RECOMMENDED.
   The following table MAY be used as default values, where X is the
   length of the delegated prefix.

   If X <= 64:  Prefix length = 64

….

Processes proposed in the appendix are optional.
Our implementation supports some part of it, and it works fine in our test-cases.
I’d rather have a /80 than no connectivity at all (And it just works.).
IMO, why64 is way too pessimistic on the current implementation state and even more when it comes to the progress implementations will do in the coming years.

And we either do that or let people do NAT66. ;)

Is it OK for you Ole ?

Cheers,

- Pierre

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 09 Oct 2014 11:29:08 +0200

Thanks for updating.

>     length is not 64.  Therefore, prefixes of length 64 are RECOMMENDED.

With this text above, operators will be encouraged to read and give /64 
to end user sites.

Alex

> IMO, why64 is way too pessimistic on the current implementation state
> and even more when it comes to the progress implementations will do in
> the coming years.
>
> Le 9 oct. 2014 à 07:25, Mark Townsley <[email-masked]
> <mailto:[email-masked]>> a écrit :
>
>>
>>
>>> On Oct 9, 2014, at 2:35 AM, Brian E Carpenter
>>> <[email-masked] <mailto:[email-masked]>> wrote:
>>>
>>>>> On 8 Oct 2014, at 14:14, Pierre Pfister <[email-masked]
>>>>> <mailto:[email-masked]>> wrote:
>>>>> Why should we mandate homenet implementations to *brake* in
>>>>> prevent a link from being configured if we actually can configure it ?
>>>>>
>>>>> If MUSTs are the solution, then I would rather see a ‘ISP MUST
>>>>> provide a /56 to customers’ than ‘Homenet MUST brake when the
>>>>> provided prefix is not big enough’.
>>>>
>>> [email-masked] <mailto:[email-masked]>
>> [email-masked] <mailto:[email-masked]>

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 09 Oct 2014 11:29:57 +0200

> the reality remains that only /64 subnets work properly in all

But this is new work, not work documenting existing practice.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 09 Oct 2014 11:40:44 +0200

Hello Pierre,

>     If X <= 64:  Prefix length = 64

I disagree.  In general, for assigning prefixes, and subsequently 
routing to them, I do not understand why should one recommend any prefix 
length at all, and even less to make it default.

This default prefix len above may prohibit one in a homenet to be an ISP 
for other smaller IoT networks.

Look, we have another draft in 6man that calls for adoption, 
draft-boucadair-6man-prefix-routing-reco-00.  That draft recommends the 
following:
>    Forwarding and routing protocols MUST NOT restrict by design the
>    length of IPv6 prefixes.  In particular, forwarding and routing
>    processes MUST be designed to accept prefixes of any length up to
>    /128.

What do you think?

Alex

---

From: Ole Troan <[email-masked]>
Date: Thu, 9 Oct 2014 13:03:23 +0200

Pierre,

I certainly understand your argument, and we don't disagree on the technical merit.

>    If X <= 64:  Prefix length = 64

the "may malfunction" is not the reason for why the IPv6 address is classful, so please don't put that as justification for a default of 64.

I would like this document to say as little as possible about the boundary.
RFC6204 says:
L-2:   The IPv6 CE router MUST assign a separate /64 from its
          delegated prefix(es) (and ULA prefix if configured to provide
          ULA addressing) for each of its LAN interfaces.

which you could tweak to fit this document as well. have text like that in one place, and then all other places threat it as an arbitrary length.

please remove the table with the description of what to do for various values of X.
I'd be happy with a statement like in RFC6204:
   WPD-3:  ...If the
           delegated prefix is too small to address all of its
           interfaces, the IPv6 CE router SHOULD log a system management
           error.

> And we either do that or let people do NAT66. ;)

I'd also remove the appendix.
it doesn't make sense to specify something that breaks SLAAC.

protocol design is politics. we want to make it clear to the address delegation authorities that not delegating a large enough address block will lead to breakage.

in my view, if we let this principle slide, then the risk isn't that the delegations are /80s, but that they will be /128s. and you're back to IPv6 NAT anyhow.

cheers,
Ole

---

From: Pierre Pfister <[email-masked]>
Date: Thu, 9 Oct 2014 13:45:02 +0200

Reply inline

> the "may malfunction" is not the reason for why the IPv6 address is classful, so please don't put that as justification for a default of 64.

I’ll change that into something more generic like: « Because of all the reasons listed in [I-D.ietf-6man-why64], prefixes of length 64 are RECOMMENDED. ». 

> please remove the table with the description of what to do for various values of X.

The algorithm treats IPv4 and IPv6 the same way, as well as any prefix lengths. 
That table is important for IPv4 support.

> it doesn't make sense to specify something that breaks SLAAC.

But you think it makes sense to specify something that breaks the network instead. That is, IMO, a curious tradeoff.

> protocol design is politics. we want to make it clear to the address delegation authorities that not delegating a large enough address block will lead to breakage.

It’s not only about the size of the prefix. It’s about all the variety of situations we will encounter.
Before the first homenet router is shipped, Hipnet-like routers (Those who do PD sub delegation) will be there. 
Mostly as CPE routers. If the ISP is kind enough to give you a /56, they will probably give you a /60. If the ISP provides a /60, they will provide a /64.
The customer will buy a *homenet enabled* router. Put it behind one of these CPEs, and won’t be able to provide a prefix on both wifi and wired networks. That works in ISP—Homenet—SubDelegation—Homenet situations too.

And broadband ISPs are not the only kind of uplinks you will have to deal with. 
- VPN service that provides you with a /64 only
- Virtualized networks
- Tethering with your phone… They are not going to provide a /56 for that (Or at least not soon enough).
- Electrical Company will probably not start giving 56s.
- etc…

And on top of that, you’ll have all the devices that require /64 prefixes and cut work without it. 
The algorithm is able to provide them with /64s and deal with smaller prefixes on the rest of the network.

Let’s dream about a world where every device will talk Homenet, but waiting for that time, we’ll have to deal with hundreds of devices that behave differently.

> in my view, if we let this principle slide, then the risk isn't that the delegations are /80s, but that they will be /128s. and you're back to IPv6 NAT anyhow.

If that really is a valuable argument, we should start breaking IPv4 so that ISPs deploy IPv6 faster.

Cheers,

- Pierre

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 10 Oct 2014 08:17:35 +1300

> With this text above, operators will be encouraged to read and give /64

Huh? This text is discussing internal subnets inside the homenet; it
has nothing to do with the ISP allocation, which is discussed in the
homenet architecture (and RFC 6177).

    Brian

---

From: Tim Chown <[email-masked]>
Date: Thu, 9 Oct 2014 20:22:53 +0100

> in my view, if we let this principle slide, then the risk isn't that the delegations are /80s, but that they will be /128s. and you're back to IPv6 NAT anyhow.

So - provocative question - should this draft be Experimental in status instead if it’s diving below /64 boundary?

Tim

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 10 Oct 2014 10:35:44 +0200

> homenet architecture (and RFC 6177).

Yes, I looked at RFC 6177 and I agree in a sense.  It is the ISP 
out-of-ones-homenet that is concerned by RFC6177 to assign more than /64 
to homenet.

But, ISPs may be interested in populating one's homenet with more than 
just 1 or 2 boxes currently.  Theyd will rather use this HNCP document 
to build one's homenets, rather than an architecture document.

At that point that ISP may become an internal-subnet-ISP in one's 
homenet.  And will tend to allocate only /64s for anything one wants to 
do in one's homenet beyond the subnets ISP builds.  And that will forbid 
one again to go beyond what ISP allows.

Which may end up in the same /64 limit.

(I speculate that however many devices ISPs put in a homenet there will 
always be some other devices they forgot but need to be there).

(one recent announcement of many devices in home is from Orange, and one 
deployed practice of always-2 boxes is from Free).

Alex

---

From: "Townsley.net" <[email-masked]>
Date: Fri, 10 Oct 2014 14:43:18 +0200

> On Oct 9, 2014, at 9:22 PM, Tim Chown <[email-masked]> wrote:
> 

No. I think you are putting way too much weight on an informational document here. 

- Mark

---

From: Tim Chown <[email-masked]>
Date: Fri, 10 Oct 2014 15:28:36 +0100

> No. I think you are putting way too much weight on an informational document here. 

Hmmm.. the draft says it’s intended status is Standards Track, not Informational?  Just a typo?

Network Working Group                                         P. Pfister
Internet-Draft                                               B. Paterson
Intended status: Standards Track                           Cisco Systems
Expires: March 23, 2015                                         J. Arkko
                                                                Ericsson
                                                      September 19, 2014

Tim

---

From: "Townsley.net" <[email-masked]>
Date: Thu, 16 Oct 2014 16:27:40 +0200

> On Oct 10, 2014, at 4:28 PM, Tim Chown <[email-masked]> wrote:
> 

I was referring to the why64 document.

- Mark

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 29 Oct 2014 19:26:11 +0100

Hi Pierre,

I took some time to understand the code.

But here is what I would like to say.

Your algorithm decides whether or not one prefix collides with another, 
by comparing prefix/plen pairs according to an exact match rule.

On another hand, the forwarding towards these prefixes is realized by 
longest-prefix match rule applied to an address against successive 
entries in a routing table.  By this rule an address/128 matches the 
first one entry whose prefix length is longest, if several; and default 
otherwise.

If one hears two prefix/plen pairs in RAs and decides they 'collide' by 
the exact match rule implemented by the code below then one may decide 
this is a bad configuration situation.  At the same time the forwarding 
may be set up ok, because it uses the longest-prefix match rule, not 
exact match, and has a default to escape to as well.

This is why I am saying that any method to compare prefixes may not be 
agreed on, may not lead to effective results, unless designed according 
to the rules used for forwarding.

Yours,

Alex