Re: [homenet] I-D Action: draft-ietf-homenet-hncp-06.txt

[Markus Stenberg]

On 27.6.2015 2.49, Juliusz Chroboczek wrote:

"  If the considered delegated prefix is an IPv6 prefix, and whenever
   there is at least one available prefix of length 64, a prefix of
   length 64 MUST be selected unless configured otherwise by an
   administrator.  In case no prefix of length 64 would be available, a
   longer prefix MAY be selected."
Well spotted, thanks.  Markus, would you be open to relaxing the MUST, 
and adding a guideline about which of the available /64s is suitable 
for carving up?

I reworded the current text as such, as I consider it sane:

   If the considered delegated prefix is an IPv6 prefix, and whenever
   there is at least one available prefix of length 64, a prefix of
   length 64 MUST be selected unless configured otherwise.  In case no
   prefix of length 64 would be available, a longer prefix MAY be
   selected even without configuration.

It does not exactly say _what_ configuration (whether provided by 
administrator, or some other process such as autonomic stuff); but by 
default, HNCP implementation MUST use /64.


Obviously, this may not be the final word if my coauthors step in or 
someone provides better language to describe the intent. I do not think 
SHOULD is good idea when describing the non-configured default which 
99+% of home routers should be doing.


Cheers,

-Markus

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] I-D Action: draft-ietf-homenet-hncp-06.txt

[Brian E Carpenter]

See below...

On 29/06/2015 09:09, Pierre Pfister wrote:
> 
> 
>> Le 28 juin 2015 à 22:00, Brian E Carpenter  a 
>> écrit :
>>
>> On 29/06/2015 01:09, Pierre Pfister wrote:
>>> Hello,
>>>
 Le 28 juin 2015 à 10:58, Gert Doering  a écrit :

 Hi,

 On Sat, Jun 27, 2015 at 11:48:43PM +0200, Pierre Pfister wrote:
> Relaxing the « administrator » may be confusing, as Brian said.
> So I guess the MUST could become a SHOULD, which imply it requires 
> implementers to fully understand the drawbacks
> of using non-64 prefix lengths. For instance, /127 could be automatically 
> used (no need for administrator) if a link
> is auto-detected as point-to-point.

 A MUST is perfectly right here.  You can't have implementation A decide
 "let's use a /64 here" while implementation B goes for "/127"…
>>>
>>> You actually can have implementations with different prefix length. 
>>> This is handled by the prefix assignment algorithm.
>>
>> Yes, you need that ability in the protocol, but it won't work in practice
>> to pick an oddball like /80 unless all the host stacks on the link can
>> handle a shorter IID like 48 (whether it's a LAN or a pt2pt). RFC 7421.
> 
> Which is why /64 SHOULD be preferred.
> We also have this:
> "In any case, a router MUST support a mechanism suitable to distribute
>addresses from the considered prefix to clients on the link.
>Otherwise it MUST NOT create or adopt it, i.e. a router assigning an
>IPv4 prefix MUST support the L-capability and a router assigning an
>IPv6 prefix not suitable for Stateless Address Autoconfiguration MUST
>support the H-capability as defined in Section 10 
> .
> "
> 
> So a router will not advertise a /80 on a typical link unless it implements 
> stageful DHCPv6.
> 
>>
>>> You may have multiple routers with multiple prefix lengths, but one single
>>> prefix is ultimately chosen and used by all routers connected to the link.
>>
>> So will it work if one router on a pt2pt expects to use a /127 and the other
>> one can only support /64?
> 
> The current document does not specify how to configure a pt2pt link.
> This could be specified later really easily, in a backward compatible way.
> Also, in general, why and how would a router assign a /64 to a pt2pt link ?

I believe that RFC 7421 was needed because, in ISP land, people were
often assigning a /64 because they thought they had to, since all
the IID mechanisms assumed /64. So there was no reason for it, it was
just human behaviour.

> I mean, considering pt2pt link, we can assume both ends of the link know the 
> nature of the link…
> and are therefore able to not do weird things such as assigning a /64 on a 
> pt2pt link.

I hope you are right. "Don't be weird" is a good motto, but "SHOULD conform
to RFC 7421" might be better in an RFC ;-).
(But then: do you want the SOHO network to automatically reserve a /64
out of which you take all the /127s for pt2pt links?)

   Brian


Brian

> 
> - Pierre
> 
>>
>>Brian
>>
>>>
>>> - Pierre
>>>

 The sentence is also clearly allowing alternatives: if I tell my router
 "hey, I want to use /127s on point-to-point links", this is "unless 
 configured 
 otherwise by an administrator", so the MUST is not getting in the way then.

 Gert Doering
   -- NetMaster
 -- 
 have you enabled IPv6 on something today...?

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

 ___
 homenet mailing list
 homenet@ietf.org
 https://www.ietf.org/mailman/listinfo/homenet
>>>
>>> ___
>>> homenet mailing list
>>> homenet@ietf.org
>>> https://www.ietf.org/mailman/listinfo/homenet
>>> .
>>>
>>
>> ___
>> homenet mailing list
>> homenet@ietf.org
>> https://www.ietf.org/mailman/listinfo/homenet
> 
> 

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] I-D Action: draft-ietf-homenet-hncp-06.txt

[Brian E Carpenter]

On 30/06/2015 04:06, Dave Taht wrote:
> On Mon, Jun 29, 2015 at 2:40 AM, Markus Stenberg  
> wrote:
>> On 26.6.2015 18.41, Juliusz Chroboczek wrote:
> 
>> Even implementation isn't limited to it.
>>
>>> And sorry if I sound like a broken record, but I would like the ability
>>> to set up a router-router link with less than a full /64 allocated to
>>> it, at least in the ad-hoc case.
>>
>>
>> I am not sure about the draft text about what it should say, as non-/64
>> seems to be a political hot potato (there are drafts on this too), but at
>> least the implementation isn't limited to this (given configuration) and the
>> draft allows for it as well (given configuration). The default of /64 seems
>> still sane to me though, given no configuration.
> 
> Regardless of whatever politics of artificial scarcity aligned to
> wasting 64 bits,
> 128s are inevitable.

Yes. My point is only that the *protocol* should allow any length, in accordance
with the IPv6 architecture. The default settings should correspond to reality.

Brian

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] I-D Action: draft-ietf-homenet-hncp-06.txt

[Dave Taht]

On Mon, Jun 29, 2015 at 2:40 AM, Markus Stenberg  wrote:
> On 26.6.2015 18.41, Juliusz Chroboczek wrote:

> Even implementation isn't limited to it.
>
>> And sorry if I sound like a broken record, but I would like the ability
>> to set up a router-router link with less than a full /64 allocated to
>> it, at least in the ad-hoc case.
>
>
> I am not sure about the draft text about what it should say, as non-/64
> seems to be a political hot potato (there are drafts on this too), but at
> least the implementation isn't limited to this (given configuration) and the
> draft allows for it as well (given configuration). The default of /64 seems
> still sane to me though, given no configuration.

Regardless of whatever politics of artificial scarcity aligned to
wasting 64 bits,
128s are inevitable.

> Cheers,
>
> -Markus
>
>
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet



-- 
Dave Täht
worldwide bufferbloat report:
http://www.dslreports.com/speedtest/results/bufferbloat
And:
What will it take to vastly improve wifi for everyone?
https://plus.google.com/u/0/explore/makewififast

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] I-D Action: draft-ietf-homenet-hncp-06.txt

[Juliusz Chroboczek]

_as far as I know_, the only part that requires transitive interfaces 
_in DNCP_ is the support for dense broadcast links.


After staring at the draft for two days, I agree.

-- Juliusz

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] I-D Action: draft-ietf-homenet-hncp-06.txt

[Markus Stenberg]

On 26.6.2015 18.41, Juliusz Chroboczek wrote:

Markus,

I still don't understand the intent of the "ad hoc" interface type.

If the ad-hoc interface is designed for non-transitive links, then the
draft should say so (in which case I'll be glad to provide you with
suitable prose).  However, in this case it should also identify the bits
of DNCP which are not applicable to non-transitive interfaces (Section
6.1.5, obviously, but I don't understand DNCP well enough to say if
there are others).


Clarifications on the text are obviously welcome and even needed :)

Due to renumbering of sections, this is bit awkward, but _as far as I 
know_, the only part that requires transitive interfaces _in DNCP_ is 
the support for dense broadcast links.


6.1.5 in dncp-06 is 'neighbor removal', and it makes no transitivity 
assumption. For each individual node, an endpoint is a local construct 
(e.g. 'this meshy eth0 interface I want to multicast+unicast on') and 
the peers that are present on it (nodes N_1.. N_n that happen to have 
been recently reachable / we have received keep-alives from / we know to 
be there by other means).



Section 4 speaks of "ad-hoc mode" -- does that mean 802.11 IBSS?  If it
is, then you should use the proper terminology, but I think that support
for non-transitive links should not be restricted to 802.11 (even if the
implementation is limited to it).


Even implementation isn't limited to it.


And sorry if I sound like a broken record, but I would like the ability
to set up a router-router link with less than a full /64 allocated to
it, at least in the ad-hoc case.


I am not sure about the draft text about what it should say, as non-/64 
seems to be a political hot potato (there are drafts on this too), but 
at least the implementation isn't limited to this (given configuration) 
and the draft allows for it as well (given configuration). The default 
of /64 seems still sane to me though, given no configuration.


Cheers,

-Markus

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] I-D Action: draft-ietf-homenet-hncp-06.txt

[Pierre Pfister]

> Le 28 juin 2015 à 22:00, Brian E Carpenter  a 
> écrit :
> 
> On 29/06/2015 01:09, Pierre Pfister wrote:
>> Hello,
>> 
>>> Le 28 juin 2015 à 10:58, Gert Doering  a écrit :
>>> 
>>> Hi,
>>> 
>>> On Sat, Jun 27, 2015 at 11:48:43PM +0200, Pierre Pfister wrote:
 Relaxing the « administrator » may be confusing, as Brian said.
 So I guess the MUST could become a SHOULD, which imply it requires 
 implementers to fully understand the drawbacks
 of using non-64 prefix lengths. For instance, /127 could be automatically 
 used (no need for administrator) if a link
 is auto-detected as point-to-point.
>>> 
>>> A MUST is perfectly right here.  You can't have implementation A decide
>>> "let's use a /64 here" while implementation B goes for "/127"…
>> 
>> You actually can have implementations with different prefix length. 
>> This is handled by the prefix assignment algorithm.
> 
> Yes, you need that ability in the protocol, but it won't work in practice
> to pick an oddball like /80 unless all the host stacks on the link can
> handle a shorter IID like 48 (whether it's a LAN or a pt2pt). RFC 7421.

Which is why /64 SHOULD be preferred.
We also have this:
"In any case, a router MUST support a mechanism suitable to distribute
   addresses from the considered prefix to clients on the link.
   Otherwise it MUST NOT create or adopt it, i.e. a router assigning an
   IPv4 prefix MUST support the L-capability and a router assigning an
   IPv6 prefix not suitable for Stateless Address Autoconfiguration MUST
   support the H-capability as defined in Section 10 
.
"

So a router will not advertise a /80 on a typical link unless it implements 
stageful DHCPv6.

> 
>> You may have multiple routers with multiple prefix lengths, but one single
>> prefix is ultimately chosen and used by all routers connected to the link.
> 
> So will it work if one router on a pt2pt expects to use a /127 and the other
> one can only support /64?

The current document does not specify how to configure a pt2pt link.
This could be specified later really easily, in a backward compatible way.
Also, in general, why and how would a router assign a /64 to a pt2pt link ?
I mean, considering pt2pt link, we can assume both ends of the link know the 
nature of the link…
and are therefore able to not do weird things such as assigning a /64 on a 
pt2pt link.

- Pierre

> 
>Brian
> 
>> 
>> - Pierre
>> 
>>> 
>>> The sentence is also clearly allowing alternatives: if I tell my router
>>> "hey, I want to use /127s on point-to-point links", this is "unless 
>>> configured 
>>> otherwise by an administrator", so the MUST is not getting in the way then.
>>> 
>>> Gert Doering
>>>   -- NetMaster
>>> -- 
>>> have you enabled IPv6 on something today...?
>>> 
>>> SpaceNet AGVorstand: Sebastian v. Bomhard
>>> Joseph-Dollinger-Bogen 14  Aufsichtsratsvors.: A. Grundner-Culemann
>>> D-80807 Muenchen   HRB: 136055 (AG Muenchen)
>>> Tel: +49 (0)89/32356-444   USt-IdNr.: DE813185279
>>> 
>>> ___
>>> homenet mailing list
>>> homenet@ietf.org
>>> https://www.ietf.org/mailman/listinfo/homenet
>> 
>> ___
>> homenet mailing list
>> homenet@ietf.org
>> https://www.ietf.org/mailman/listinfo/homenet
>> .
>> 
> 
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] I-D Action: draft-ietf-homenet-hncp-06.txt

[Pierre Pfister]

Hello Juliusz,

No, as it is specified for now, a router cannot assign an address on an 
end-point 
unless that en-point is in a ‘Common Link’ which includes the end-point 
identifier.
"An assigned address MUST be in the first quarter of an assigned
  prefix currently applied on a Common Link which includes the
  interface specified by the endpoint identifier."

The address assignment process does not require this limitation though. I guess 
we could consider removing that.

But if what you are trying to do is assign sparse /128 to different links or 
loopbacks, there exists a perfectly valid way to do so.
A router can assign a /128 prefix for private use (just like it would do a PD, 
i.e., by advertising an ASSIGNED-PREFIX TLV with an End-Point ID equal to 0, 
or even another End-Point ID that is not used by any real interfaces), and use 
the address (And advertise it through the RP, 
just like it would do with any other assigned prefix).

- Pierre


> Le 28 juin 2015 à 16:22, Juliusz Chroboczek  
> a écrit :
> 
> Concerning the /128-on-loopback issue...
> 
> The HNCP draft is not quite clear about the semantics of the NODE-ADDRESS TLV 
> (Section 6.3 of -06).  Is that for on-link addresses only?
> 
> In other words, is it legal for a router to grab an address from a prefix 
> assigned by some other router (not necessarily a neighbour), advertise it 
> over NODE-ADDRESS, assign it to one if its interfaces, and advertise the /128 
> over Babel?
> 
> If it's legal and doesn't cause any issues I don't see, then that pretty much 
> solves this particular problem.
> 
> -- Juliusz
> 
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] I-D Action: draft-ietf-homenet-hncp-06.txt

[Brian E Carpenter]

On 29/06/2015 01:09, Pierre Pfister wrote:
> Hello,
> 
>> Le 28 juin 2015 à 10:58, Gert Doering  a écrit :
>>
>> Hi,
>>
>> On Sat, Jun 27, 2015 at 11:48:43PM +0200, Pierre Pfister wrote:
>>> Relaxing the « administrator » may be confusing, as Brian said.
>>> So I guess the MUST could become a SHOULD, which imply it requires 
>>> implementers to fully understand the drawbacks
>>> of using non-64 prefix lengths. For instance, /127 could be automatically 
>>> used (no need for administrator) if a link
>>> is auto-detected as point-to-point.
>>
>> A MUST is perfectly right here.  You can't have implementation A decide
>> "let's use a /64 here" while implementation B goes for "/127"…
> 
> You actually can have implementations with different prefix length. 
> This is handled by the prefix assignment algorithm.

Yes, you need that ability in the protocol, but it won't work in practice
to pick an oddball like /80 unless all the host stacks on the link can
handle a shorter IID like 48 (whether it's a LAN or a pt2pt). RFC 7421.

> You may have multiple routers with multiple prefix lengths, but one single
> prefix is ultimately chosen and used by all routers connected to the link.

So will it work if one router on a pt2pt expects to use a /127 and the other
one can only support /64?

Brian

> 
> - Pierre
> 
>>
>> The sentence is also clearly allowing alternatives: if I tell my router
>> "hey, I want to use /127s on point-to-point links", this is "unless 
>> configured 
>> otherwise by an administrator", so the MUST is not getting in the way then.
>>
>> Gert Doering
>>-- NetMaster
>> -- 
>> have you enabled IPv6 on something today...?
>>
>> SpaceNet AGVorstand: Sebastian v. Bomhard
>> Joseph-Dollinger-Bogen 14  Aufsichtsratsvors.: A. Grundner-Culemann
>> D-80807 Muenchen   HRB: 136055 (AG Muenchen)
>> Tel: +49 (0)89/32356-444   USt-IdNr.: DE813185279
>>
>> ___
>> homenet mailing list
>> homenet@ietf.org
>> https://www.ietf.org/mailman/listinfo/homenet
> 
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
> .
> 

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] I-D Action: draft-ietf-homenet-hncp-06.txt

[Juliusz Chroboczek]

Concerning the /128-on-loopback issue...

The HNCP draft is not quite clear about the semantics of the NODE-ADDRESS 
TLV (Section 6.3 of -06).  Is that for on-link addresses only?


In other words, is it legal for a router to grab an address from a prefix 
assigned by some other router (not necessarily a neighbour), advertise it 
over NODE-ADDRESS, assign it to one if its interfaces, and advertise the 
/128 over Babel?


If it's legal and doesn't cause any issues I don't see, then that pretty 
much solves this particular problem.


-- Juliusz

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] I-D Action: draft-ietf-homenet-hncp-06.txt

[Pierre Pfister]

Hello,

> Le 28 juin 2015 à 10:58, Gert Doering  a écrit :
> 
> Hi,
> 
> On Sat, Jun 27, 2015 at 11:48:43PM +0200, Pierre Pfister wrote:
>> Relaxing the « administrator » may be confusing, as Brian said.
>> So I guess the MUST could become a SHOULD, which imply it requires 
>> implementers to fully understand the drawbacks
>> of using non-64 prefix lengths. For instance, /127 could be automatically 
>> used (no need for administrator) if a link
>> is auto-detected as point-to-point.
> 
> A MUST is perfectly right here.  You can't have implementation A decide
> "let's use a /64 here" while implementation B goes for "/127"…

You actually can have implementations with different prefix length. 
This is handled by the prefix assignment algorithm.
You may have multiple routers with multiple prefix lengths, but one single
prefix is ultimately chosen and used by all routers connected to the link.

- Pierre

> 
> The sentence is also clearly allowing alternatives: if I tell my router
> "hey, I want to use /127s on point-to-point links", this is "unless 
> configured 
> otherwise by an administrator", so the MUST is not getting in the way then.
> 
> Gert Doering
>-- NetMaster
> -- 
> have you enabled IPv6 on something today...?
> 
> SpaceNet AGVorstand: Sebastian v. Bomhard
> Joseph-Dollinger-Bogen 14  Aufsichtsratsvors.: A. Grundner-Culemann
> D-80807 Muenchen   HRB: 136055 (AG Muenchen)
> Tel: +49 (0)89/32356-444   USt-IdNr.: DE813185279
> 
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] I-D Action: draft-ietf-homenet-hncp-06.txt

[Gert Doering]

Hi,

On Sat, Jun 27, 2015 at 11:48:43PM +0200, Pierre Pfister wrote:
> Relaxing the « administrator » may be confusing, as Brian said.
> So I guess the MUST could become a SHOULD, which imply it requires 
> implementers to fully understand the drawbacks
> of using non-64 prefix lengths. For instance, /127 could be automatically 
> used (no need for administrator) if a link
> is auto-detected as point-to-point.

A MUST is perfectly right here.  You can't have implementation A decide
"let's use a /64 here" while implementation B goes for "/127"...

The sentence is also clearly allowing alternatives: if I tell my router
"hey, I want to use /127s on point-to-point links", this is "unless configured 
otherwise by an administrator", so the MUST is not getting in the way then.

Gert Doering
-- NetMaster
-- 
have you enabled IPv6 on something today...?

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

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] I-D Action: draft-ietf-homenet-hncp-06.txt

[Pierre Pfister]

Hello Juliusz and Brian,

I agree with you both. The text is actually how it is because of strong 
opinions I received from others.
IMO, 64 should be preferred as long as it does not harm the network 
(or in cases where it is obviously not necessary, such as point-to-point links).

Relaxing the « administrator » may be confusing, as Brian said.
So I guess the MUST could become a SHOULD, which imply it requires implementers 
to fully understand the drawbacks
of using non-64 prefix lengths. For instance, /127 could be automatically used 
(no need for administrator) if a link
is auto-detected as point-to-point.

- Pierre

> 
>>> +10 on /128 support.
> 
>> If you mean RFC6164, that would be a /127 prefix.
> 
> I think Dave meant no on-link information, which unless I'm mistaken is 
> equivalent to putting a /128 on the interface.  With explicitly scoped 
> link-local addresses, on-link information becomes a mere optimisation 
> (although an important one in the multihomed host case, where redirects 
> cannot cause you to switch interfaces).
> 
>> "  If the considered delegated prefix is an IPv6 prefix, and whenever
>>   there is at least one available prefix of length 64, a prefix of
>>   length 64 MUST be selected unless configured otherwise by an
>>   administrator.  In case no prefix of length 64 would be available, a
>>   longer prefix MAY be selected."
> 
> Well spotted, thanks.  Markus, would you be open to relaxing the MUST, and 
> adding a guideline about which of the available /64s is suitable for carving 
> up?
> 
> -- Juliusz
> 
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] I-D Action: draft-ietf-homenet-hncp-06.txt

[Brian E Carpenter]

On 28/06/2015 06:25, Michael Richardson wrote:
> 
> >>> And sorry if I sound like a broken record, but I would like the 
> ability to
> >>> set up a router-router link with less than a full /64 allocated to 
> it, at
> >>> least in the ad-hoc case.
> 
> Not sure who said this part.
> 
> My question is: for a router/router link, even if it's really ethernet rather
> than PPP, why wouldn't one use *just* link-local addresses?  

As long as you don't break the rules by using those addresses in ICMP replies.

   Brian

> While I have
> encountered a few OSPFv3 implementations that wouldn't run over link-local
> addresses, the vendors admitted that it was a bug. (That equipment got
> obsoleted due to 512K limit on v4 routing slots before that got fixed though)
> 
> If there something in HNCP that would require router/router links to be
> numbered?   Or is it a case of, one just doesn't *know* that there will never
> be end-hosts on the link.   If one requires manual intervention to allocate
> a prefix longer than /64 to a link, then one could also just say it was a
> router-only link.
> 
> --
> Michael Richardson , Sandelman Software Works
>  -= IPv6 IoT consulting =-
> 
> 
> 
> 
> 
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
> 

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] I-D Action: draft-ietf-homenet-hncp-06.txt

[Michael Richardson]

>>> And sorry if I sound like a broken record, but I would like the ability 
to
>>> set up a router-router link with less than a full /64 allocated to it, 
at
>>> least in the ad-hoc case.

Not sure who said this part.

My question is: for a router/router link, even if it's really ethernet rather
than PPP, why wouldn't one use *just* link-local addresses?  While I have
encountered a few OSPFv3 implementations that wouldn't run over link-local
addresses, the vendors admitted that it was a bug. (That equipment got
obsoleted due to 512K limit on v4 routing slots before that got fixed though)

If there something in HNCP that would require router/router links to be
numbered?   Or is it a case of, one just doesn't *know* that there will never
be end-hosts on the link.   If one requires manual intervention to allocate
a prefix longer than /64 to a link, then one could also just say it was a
router-only link.

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] I-D Action: draft-ietf-homenet-hncp-06.txt

[Juliusz Chroboczek]

+10 on /128 support.



If you mean RFC6164, that would be a /127 prefix.


I think Dave meant no on-link information, which unless I'm mistaken is 
equivalent to putting a /128 on the interface.  With explicitly scoped 
link-local addresses, on-link information becomes a mere optimisation 
(although an important one in the multihomed host case, where redirects 
cannot cause you to switch interfaces).



"  If the considered delegated prefix is an IPv6 prefix, and whenever
   there is at least one available prefix of length 64, a prefix of
   length 64 MUST be selected unless configured otherwise by an
   administrator.  In case no prefix of length 64 would be available, a
   longer prefix MAY be selected."


Well spotted, thanks.  Markus, would you be open to relaxing the MUST, and 
adding a guideline about which of the available /64s is suitable for 
carving up?


-- Juliusz

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] I-D Action: draft-ietf-homenet-hncp-06.txt

[Brian E Carpenter]

On 27/06/2015 04:19, Dave Taht wrote:
> On Fri, Jun 26, 2015 at 8:41 AM, Juliusz Chroboczek
>  wrote:

...
>> And sorry if I sound like a broken record, but I would like the ability to
>> set up a router-router link with less than a full /64 allocated to it, at
>> least in the ad-hoc case.
> 
> +10 on /128 support.
> 
> I have way more p2p links than available 64s.

If you mean RFC6164, that would be a /127 prefix. But in any case /64 is not
sacred in IPv6. https://tools.ietf.org/html/draft-ietf-v6ops-cidr-prefix-03
was just approved by the IESG and is in the RFC Editor queue.
Any prefix length must be possible, even if /64 is preferred.

Which is actually what the draft says, in slightly strange syntax:

"  If the considered delegated prefix is an IPv6 prefix, and whenever
   there is at least one available prefix of length 64, a prefix of
   length 64 MUST be selected unless configured otherwise by an
   administrator.  In case no prefix of length 64 would be available, a
   longer prefix MAY be selected."

I'm not sure about the words "by an administrator". With my autonomic
networking hat on, I feel that configuration might arise with no human
intervention. But in any case, even given that homenet wants to prefer
/64, any length must be allowed.

Brian

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] I-D Action: draft-ietf-homenet-hncp-06.txt

[Dave Taht]

On Fri, Jun 26, 2015 at 8:41 AM, Juliusz Chroboczek
 wrote:
> Markus,
>
> I still don't understand the intent of the "ad hoc" interface type.
>
> If the ad-hoc interface is designed for non-transitive links, then the draft
> should say so (in which case I'll be glad to provide you with suitable
> prose).  However, in this case it should also identify the bits of DNCP
> which are not applicable to non-transitive interfaces (Section 6.1.5,
> obviously, but I don't understand DNCP well enough to say if there are
> others).
>
> Section 4 speaks of "ad-hoc mode" -- does that mean 802.11 IBSS?  If it is,
> then you should use the proper terminology, but I think that support for
> non-transitive links should not be restricted to 802.11 (even if the
> implementation is limited to it).
>
> And sorry if I sound like a broken record, but I would like the ability to
> set up a router-router link with less than a full /64 allocated to it, at
> least in the ad-hoc case.

+10 on /128 support.

I have way more p2p links than available 64s.

> -- Juliusz
>
>
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet



-- 
Dave Täht
worldwide bufferbloat report:
http://www.dslreports.com/speedtest/results/bufferbloat
And:
What will it take to vastly improve wifi for everyone?
https://plus.google.com/u/0/explore/makewififast

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] I-D Action: draft-ietf-homenet-hncp-06.txt

[Juliusz Chroboczek]

If a router speaks DHCPv4 or DHCPv6-PD with a user-class of "HOMENET" but 
doesn't speak HNCP, nothing will break, right?  (Perhaps a second 
User-Class like "HOMENET-COMPATIBLE" should be defined for this case, as 
this may simplify debugging.)


I'm an idiot.  Please ignore this paragraph.

-- Juliusz

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] I-D Action: draft-ietf-homenet-hncp-06.txt

[Juliusz Chroboczek]

Trying to wrap my head around Section 5, so please bear with me.

If there's an IPv6-only non-Homenet router that doesn't provide PD (either 
because it only does DHCPv6 address assignment, or because it only 
advertises RA), then the link will be considered internal.  Is that correct?


If a router speaks DHCPv4 or DHCPv6-PD with a user-class of "HOMENET" but 
doesn't speak HNCP, nothing will break, right?  (Perhaps a second 
User-Class like "HOMENET-COMPATIBLE" should be defined for this case, as 
this may simplify debugging.)


Thanks,

-- Juliusz




___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] I-D Action: draft-ietf-homenet-hncp-06.txt

[Juliusz Chroboczek]

Markus,

I still don't understand the intent of the "ad hoc" interface type.

If the ad-hoc interface is designed for non-transitive links, then the 
draft should say so (in which case I'll be glad to provide you with 
suitable prose).  However, in this case it should also identify the bits 
of DNCP which are not applicable to non-transitive interfaces (Section 
6.1.5, obviously, but I don't understand DNCP well enough to say if there 
are others).


Section 4 speaks of "ad-hoc mode" -- does that mean 802.11 IBSS?  If it 
is, then you should use the proper terminology, but I think that support 
for non-transitive links should not be restricted to 802.11 (even if the 
implementation is limited to it).


And sorry if I sound like a broken record, but I would like the ability to 
set up a router-router link with less than a full /64 allocated to it, at 
least in the ad-hoc case.


-- Juliusz

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] I-D Action: draft-ietf-homenet-hncp-06.txt

[Markus Stenberg]

On 17.6.2015 19.37, internet-dra...@ietf.org wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.
  This draft is a work item of the Home Networking Working Group of the IETF.

 Title   : Home Networking Control Protocol
 Authors : Markus Stenberg
   Steven Barth
   Pierre Pfister
Filename: draft-ietf-homenet-hncp-06.txt
Pages   : 31
Date: 2015-06-17

Abstract:
This document describes the Home Networking Control Protocol (HNCP),
an extensible configuration protocol and a set of requirements for
home network devices on top of the Distributed Node Consensus
Protocol (DNCP).  It enables automated configuration of addresses,
naming, network borders and the seamless use of a routing protocol.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-homenet-hncp/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-homenet-hncp-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-homenet-hncp-06



We updated the HNCP draft based on WG chairs' comments (and some 
others). No operational changes. We consider it ready for WGLC, although 
it still could use either direct editing or further review by more people.


Updated DNCP draft will follow later this week, based on feedback from 
Thomas Clausen and some internal review.


Cheers,

-Markus

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

[homenet] I-D Action: draft-ietf-homenet-hncp-06.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Home Networking Working Group of the IETF.

Title   : Home Networking Control Protocol
Authors : Markus Stenberg
  Steven Barth
  Pierre Pfister
Filename: draft-ietf-homenet-hncp-06.txt
Pages   : 31
Date: 2015-06-17

Abstract:
   This document describes the Home Networking Control Protocol (HNCP),
   an extensible configuration protocol and a set of requirements for
   home network devices on top of the Distributed Node Consensus
   Protocol (DNCP).  It enables automated configuration of addresses,
   naming, network borders and the seamless use of a routing protocol.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-homenet-hncp/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-homenet-hncp-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-homenet-hncp-06


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet