Re: [homenet] I-D.ietf-homenet-prefix-assignment (RFC 4193 conformance)

[Pierre Pfister]

Hello Brian and James,

Thanks for the heads up. CANs will be replaced in next version.

So I’m clarifying the two first points in 4.3

   o  It can be delegated by a service provider (DHCPv6 PD, 6rd
  [RFC5969], etc..).

   o  It can be provisioned by an administrative authority (user
  configuration, netconf [RFC6241], etc... ).

And changing the last paragraph of the ULA generation section.

   Note as well that this section doesn't prevent multiple ULA prefixes
   from existing simultaneously.  ULA prefixes may be provided by
   different means, as specified in Section 4.3.  Delegated prefixes
   that are delegated by a service provider or provisioned by an
   authority differ from 'spontaneously' generated prefixes.  They MUST
   NOT be withdrawn if another ULA delegated prefix is observed.


Cheers,

- Pierre


Le 9 oct. 2014 à 22:49, James Woodyatt  a écrit :

> On Thu, Oct 9, 2014 at 12:26 PM, Pierre Pfister  
> wrote:
> 
> But I’m going to change it and making it more clear that authorities can 
> provide their own prefixes. Even ULAs.
> 
> Thanks! I'm very pleased to see this agreement.
>  
> 
> -- 
> james woodyatt 
> Nest Labs, Communications Engineering
> ___
> 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.ietf-homenet-prefix-assignment (RFC 4193 conformance)

[James Woodyatt]

On Thu, Oct 9, 2014 at 12:26 PM, Pierre Pfister 
wrote:

>
> But I’m going to change it and making it more clear that authorities can
> provide their own prefixes. Even ULAs.
>

Thanks! I'm very pleased to see this agreement.


-- 
james woodyatt 
Nest Labs, Communications Engineering
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] I-D.ietf-homenet-prefix-assignment (RFC 4193 conformance)

[Pierre Pfister]

> 
> I think my concern might be ameliorated by drawing a distinction in the 
> requirements between a single distinguished Home ULA Prefix and any number of 
> other Exterior ULA Prefix delegations.  The former prefix is autonomously 
> generated by the HOMENET router in the Leader role, whereas the latter are 
> delegated by exterior numbering authorities outside the HOMENET domain, and 
> they are just like any other globally scoped IPv6 network prefix.
> 

There is no intent to prevent that at all. And I totally agree with you that 
ULAs are just prefixes like other.
The last paragraph I put here is just a reminder that, exactly as you want, you 
can have has many ULA prefixes as you want when they are provided by the mean 
of the two first points of section 4.3.

   o  It can be dynamically delegated, for instance using DHCPv6 PD.

   o  It can be created statically, specified in router's configuration.


The first point is what you want. "delegated by exterior numbering authorities 
outside the HOMENET" perfectly fits to the first point.
I mean, it can be using DHCP-PD, netconf, static conf, or any other means.

It’s funny cause it looks like adding that last paragraph, that intended to 
clarify, i making it less clear.

But I’m going to change it and making it more clear that authorities can 
provide their own prefixes. Even ULAs.

Cheers

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

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

[Tim Chown]

On 9 Oct 2014, at 12:03, Ole Troan  wrote:

> 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.

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

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

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

[Brian E Carpenter]

On 09/10/2014 22:29, Alexandru Petrescu wrote:
> Thanks for updating.
> 
> Le 09/10/2014 11:26, Pierre Pfister a écrit :
>> 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.
> 
> With this text above, operators will be encouraged to read and give /64
> to end user sites.

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

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

Re: [homenet] I-D.ietf-homenet-prefix-assignment (RFC 4193 conformance)

[Brian E Carpenter]

Works for me, but for RFC 2119, s/CAN/MAY/.

Thanks
   Brian

On 09/10/2014 22:04, Pierre Pfister wrote:
> Hello James and Brian,
> 
> What do you think of the following proposal ?
> It allows any router to generate a ULA (it adds more complexity because 
> collisions must be avoided, even though the Backoff was necessary at boot 
> anyway).
> And it conforms to RFC4193 whenever possible (date is available and stable 
> storage can be used).
> 
> 
> 9.1.  ULA Prefix Generation
> 
>A router MAY spontaneously generate a ULA delegated prefix whenever
>the two following conditions are met.
> 
>o  No other ULA delegated prefix is being advertised network-wide.
> 
>o  The ULA Backoff Timer is not running.
> 
>A router MUST stop advertising a spontaneously generated ULA prefix
>whenever another router is advertising a ULA delegated prefix.
> 
>At startup, the ULA Backoff Timer is set to a random value between 0
>and ULA_DELAY_FACTOR * FLOODING_DELAY.  Whenever some other router
>starts advertising a ULA prefix, all routers except the Network
>Leader (Section 4.4) increase their Backoff Timer to a random value
>between 0 and ULA_DELAY_FACTOR * FLOODING_DELAY.
> 
>ULA_DELAY_FACTOR initial value is 2 and is doubled each time the
>router has to withdraw its own spontaneously generated ULA prefix due
>to a collision.  The ULA_DELAY_FACTOR is reset to 2 if at least one
>ULA delegated prefix is advertised network-wide and no new ULA
>delegated prefix is advertised, for a lapse of time of 4 *
>FLOODING_DELAY.
> 
>The most recently used ULA prefix SHOULD be stored in stable storage
>and reused whenever generating a ULA delegated prefix.  If no ULA
>prefix can be found in the stable storage, it MUST be randomly
>generated.
> 
>ULA prefix generation SHOULD conform to [RFC4193].  Nevertheless, if
>the stable storage can't be used or the current date cannot be
>determined, the prefix CAN be pseudo-randomly generated based on
>hardware specific values.
> 
>Not as well that this section doesn't prevent multiple ULA prefixes
>from existing simultaneously.  ULA prefixes may be provided by
>DHCPv6-PD or static configuration, as specified in Section 4.3, in
>which case they are not considered as 'spontaneously' generated and
>MUST NOT be withdrawn if another ULA delegated prefix is observed.
> 
> 
> 
> Le 9 oct. 2014 à 02:45, Mark Andrews  a écrit :
> 
>> Why are we arguing about this?
>>
>> You need to be able to *set* the ULA prefix to something that is
>> externally generated.  This needs to remembered across reboots,
>> power cycles etc.
>>
>> There is no point in having a stable algorithm to generate a ULA
>> prefix.  As far as I can see the only purpose is to avoid having
>> any non-volatile memory in the box and I don't see that as a realistic
>> box.
>>
>> You will also need non-volatile memory for internal prefix delegation
>> etc.  You you do want the same prefix to be handed to the same
>> internal router regardless of the request order.
>>
>> -- 
>> Mark Andrews, ISC
>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
>>
>> ___
>> 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.ietf-homenet-prefix-assignment (RFC 4193 conformance)

[James Woodyatt]

On Thu, Oct 9, 2014 at 2:04 AM, Pierre Pfister 
wrote:

>
> What do you think of the following proposal ?
> It allows any router to generate a ULA (it adds more complexity because
> collisions must be avoided, even though the Backoff was necessary at boot
> anyway).
>

As this is a Standards Track requirements draft, I hope to be excused if
I'm seeming to be overly pedantic, but this revision still leaves me
concerned that we are setting requirements that do not admit Thread
networks into HOMENET routing domains.  Here is the excerpt that I find
most troubling:

ULA prefixes may be provided by DHCPv6-PD or static configuration, as
specified in Section 4.3, in which case they are not considered as
"spontaneously" generated and MUST NOT be withdrawn if another ULA
delegated prefix is observed.


My problem is that Thread networks autonomously number themselves with a
ULA /64 prefix, i.e. a ULA /48 prefix with a well-known 16-bit subnet
identifier. This happens when the first element in a disconnected network
commissions itself. Thread networks will keep this /64 prefix as more
elements are commissioned with network credentials to join the mesh. In the
highly likely event that one or more elements capable of acting as Thread
border routers to the HOMENET domain later join the mesh, then each of them
would naturally want to advertise into the HOMENET domain this autonomously
generated ULA /64 prefix. The language in this proposed revision still
seems to admit only ULA delegated prefixes obtained by DHCPv6-PD and by
*static* configuration, but neither of those are applicable in the case of
Thread networks.

I think my concern might be ameliorated by drawing a distinction in the
requirements between a single distinguished Home ULA Prefix and any number
of other Exterior ULA Prefix delegations.  The former prefix is
autonomously generated by the HOMENET router in the Leader role, whereas
the latter are delegated by exterior numbering authorities outside the
HOMENET domain, and they are just like any other globally scoped IPv6
network prefix.

Would it be helpful if I tried to write up a proposed set of edits for this?


-- 
james woodyatt 
Nest Labs, Communications Engineering
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Request for Comments on New Internet Draft for Homenet WG

[Markus Stenberg]

Heya,

it seems to be aiming to work only within link-local collision domain, and 
therefore it seems to be outside the work homenet WG is chartered to do. 
Perhaps dnssd is more appropriate for this work, although I am not sure about 
that either (they do more than just naming, as the focus is on service 
discovery).

Also, I am not sure why you are not just using mDNS (RFC6762) or SSDP (of UPnP) 
or something else; you get service discovery AND naming with them.

Finally, use of DNSSL option for this seems like a bad idea. For example, let’s 
assume my ISP gives me ’services.isp.com’ search path, and it gets propagated 
to my LAN. My devices start showing up under ..services.isp.com names (too) :-p

Cheers,

-Markus

P.S. Name construction scheme is interesting.
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

[homenet] Request for Comments on New Internet Draft for Homenet WG

[Mr. Jaehoon Paul Jeong]

Hi all,

I submitted a new Internet Draft about "DNS name autoconfiguration for Home
network or IoT devices".

The DNS name autoconfiguration for home network devices will be useful
for the IPv6 stateless autoconfiguration of Home network (or IoT) devices
along with
RFC 6106 for "IPv6 Router Advertisement Options for DNS Configuration":
http://datatracker.ietf.org/doc/rfc6106/

The following is my draft information:
Title: DNS Name Autoconfiguration for Home Network Devices
   draft-jeong-homenet-device-name-autoconf-01

http://datatracker.ietf.org/doc/draft-jeong-homenet-device-name-autoconf/

Abstract:
   This document specifies an autoconfiguration scheme for DNS names of
   home network devices.  By this scheme, the DNS name of a home network
   device can be autoconfigured with the device's category and model in
   a home network.  This DNS name lets home residents easily identify
   each device for monitoring and remote-controlling it in a home
   network.

I would like to ask you to take a look at my new draft and give me your
valuable feedback.

In this IETF 91 meeting, I hope to present my draft and discuss with you
whether my new proposal can be developed for a new working item in Homenet
WG.

Thanks.

Best Regards,
Paul
===
Mr. Jaehoon (Paul) Jeong, Ph.D.
Assistant Professor
Department of Software /
Department of Computer Engineering
Sungkyunkwan University
Office: +82-31-299-4957
Mobile: +82-10-4758-1765
Fax: +82-31-290-5119
Email: paulje...@skku.edu, jaehoon.p...@gmail.com
CPS Lab Website: http://cpslab.skku.edu
Personal Homepage: http://cpslab.skku.edu/people-jaehoon-jeong.php
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Pierre Pfister]

Reply inline


Le 9 oct. 2014 à 13:03, Ole Troan  a écrit :

> Pierre,
> 
> I certainly understand your argument, and we don't disagree on the technical 
> merit.
> 
>> 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
> 
> 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. ». 

> 
> 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.

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

> 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.
> 
>> 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 ?
> 
> I'd also remove the appendix.
> 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
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Ole Troan]

Pierre,

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

> 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

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.

> 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 ?

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

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

[homenet] Fwd: ANIMA charter: status update

[Benoit Claise]

FYI, just in case you're not subscribed to ANIMA.

Regards, Benoit


 Original Message 
Subject:ANIMA charter: status update
Date:   Thu, 09 Oct 2014 11:52:12 +0200
From:   Benoit Claise 
To: an...@ietf.org 



Dear all,

From the minutes of the October 2, 2014 IESG Teleconference

 o Autonomic Networking Integrated Model and Approach (anima) - 4 of 4
Area: OPS (Benoit Claise)

   The IESG approved the draft WG charter for IETF review pending edits to
   the text of the charter to be supplied by Benoit Claise.  The
   Secretariat will send a WG Review announcement, with a separate message
   tonew-w...@ietf.org.

I updated the ANIMA charter based on the IESG feedback.
See https://datatracker.ietf.org/doc/charter-ietf-anima/

I have NOT included any of the HOMENET related feedback at this point.
My goal is to listen to all feedback during the external review period, 
and then to decide which of the WG or the second BoF is the most 
appropriate next step. Reminder: a slot has been secured in the agenda.
The discussion with HOMENET (and any other WG or potentially SDO) is 
both healthy and necessary.


Regards, Benoit


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

Re: [homenet] [Anima] Homenet feedback on the ANIMA charter

[Benoit Claise]

On 02/10/2014 14:57, Laurent Ciavaglia wrote:

Dear Benoit, Markus, all,

On 02/10/2014 14:16, Benoit Claise wrote:

On 01/10/2014 18:27, Markus Stenberg wrote:


Notably, adoption of a solution (discovery+negotiation protocol) before 
adoption of use cases seems like putting cart before the horse.

Valid point.

Regards, Benoit


Indeed a valid point, however before concluding here, some insights 
might help:
-OPS ADs gave guidance to focus on (applicability on) 2 use cases 
only.
-The solution adoption milestone shall read as _applicability_ of 
the protocols onto the two proposed/elected use cases (the milestone 
should be rewritten in that sense for more clarity).
-The WG aims at developing protocols reusable _among __multiple_ 
use cases.
-An initial step of the WG should be to extract, from these 
multiple use cases, the boundaries / problems these protocols have to 
solve.

The charter has been updated to reflect this.

Regards, Benoit



HTH, best regards, Laurent.



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

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

[Alexandru Petrescu]

Hello Pierre,

Le 09/10/2014 11:26, Pierre Pfister a écrit :
[...]

The following table MAY be used as default values, where X is the
length of the delegated prefix.

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




….

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

Le 9 oct. 2014 à 07:25, Mark Townsley mailto:m...@townsley.net>> a écrit :





On Oct 9, 2014, at 2:35 AM, Brian E Carpenter
mailto:brian.e.carpen...@gmail.com>> wrote:


On 09/10/2014 03:21, Tim Chown wrote:

On 8 Oct 2014, at 14:14, Pierre Pfister mailto:pierre.pfis...@darou.fr>> wrote:
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’.


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.


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


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
the reality remains that only /64 subnets work properly in all
circumstances today.

  Brian

___
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] homenet-prefix-assignment update - prefix length 64 and on prefix comparison

[Alexandru Petrescu]

Le 09/10/2014 02:35, Brian E Carpenter a écrit :

On 09/10/2014 03:21, Tim Chown wrote:

On 8 Oct 2014, at 14:14, Pierre Pfister  wrote:

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’.


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.


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.


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

Alex



 Brian






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

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

[Alexandru Petrescu]

Thanks for updating.

Le 09/10/2014 11:26, Pierre Pfister a écrit :

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.


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


Alex


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

Le 9 oct. 2014 à 07:25, Mark Townsley mailto:m...@townsley.net>> a écrit :





On Oct 9, 2014, at 2:35 AM, Brian E Carpenter
mailto:brian.e.carpen...@gmail.com>> wrote:


On 09/10/2014 03:21, Tim Chown wrote:

On 8 Oct 2014, at 14:14, Pierre Pfister mailto:pierre.pfis...@darou.fr>> wrote:
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’.


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.


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


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
the reality remains that only /64 subnets work properly in all
circumstances today.

  Brian

___
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] homenet-prefix-assignment update - prefix length 64 and on prefix comparison

[Pierre Pfister]

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

Le 9 oct. 2014 à 07:25, Mark Townsley  a écrit :

> 
> 
>> On Oct 9, 2014, at 2:35 AM, Brian E Carpenter  
>> wrote:
>> 
>>> On 09/10/2014 03:21, Tim Chown wrote:
 On 8 Oct 2014, at 14:14, Pierre Pfister  wrote:
 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’.
>>> 
>>> 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.
>> 
>> And could be added as a reference. It's already in IESG Evaluation
>> (with one open issue that was just flagged).
> 
> 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
>> the reality remains that only /64 subnets work properly in all
>> circumstances today.
>> 
>>   Brian
>> 
>> ___
>> 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.ietf-homenet-prefix-assignment (RFC 4193 conformance)

[Pierre Pfister]

Hello James and Brian,

What do you think of the following proposal ?
It allows any router to generate a ULA (it adds more complexity because 
collisions must be avoided, even though the Backoff was necessary at boot 
anyway).
And it conforms to RFC4193 whenever possible (date is available and stable 
storage can be used).


9.1.  ULA Prefix Generation

   A router MAY spontaneously generate a ULA delegated prefix whenever
   the two following conditions are met.

   o  No other ULA delegated prefix is being advertised network-wide.

   o  The ULA Backoff Timer is not running.

   A router MUST stop advertising a spontaneously generated ULA prefix
   whenever another router is advertising a ULA delegated prefix.

   At startup, the ULA Backoff Timer is set to a random value between 0
   and ULA_DELAY_FACTOR * FLOODING_DELAY.  Whenever some other router
   starts advertising a ULA prefix, all routers except the Network
   Leader (Section 4.4) increase their Backoff Timer to a random value
   between 0 and ULA_DELAY_FACTOR * FLOODING_DELAY.

   ULA_DELAY_FACTOR initial value is 2 and is doubled each time the
   router has to withdraw its own spontaneously generated ULA prefix due
   to a collision.  The ULA_DELAY_FACTOR is reset to 2 if at least one
   ULA delegated prefix is advertised network-wide and no new ULA
   delegated prefix is advertised, for a lapse of time of 4 *
   FLOODING_DELAY.

   The most recently used ULA prefix SHOULD be stored in stable storage
   and reused whenever generating a ULA delegated prefix.  If no ULA
   prefix can be found in the stable storage, it MUST be randomly
   generated.

   ULA prefix generation SHOULD conform to [RFC4193].  Nevertheless, if
   the stable storage can't be used or the current date cannot be
   determined, the prefix CAN be pseudo-randomly generated based on
   hardware specific values.

   Not as well that this section doesn't prevent multiple ULA prefixes
   from existing simultaneously.  ULA prefixes may be provided by
   DHCPv6-PD or static configuration, as specified in Section 4.3, in
   which case they are not considered as 'spontaneously' generated and
   MUST NOT be withdrawn if another ULA delegated prefix is observed.



Le 9 oct. 2014 à 02:45, Mark Andrews  a écrit :

> 
> Why are we arguing about this?
> 
> You need to be able to *set* the ULA prefix to something that is
> externally generated.  This needs to remembered across reboots,
> power cycles etc.
> 
> There is no point in having a stable algorithm to generate a ULA
> prefix.  As far as I can see the only purpose is to avoid having
> any non-volatile memory in the box and I don't see that as a realistic
> box.
> 
> You will also need non-volatile memory for internal prefix delegation
> etc.  You you do want the same prefix to be handed to the same
> internal router regardless of the request order.
> 
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
> 
> ___
> 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