Re: [homenet] Orchestration of renumbering

[Ted Lemon]

On Mar 25, 2015, at 2:44 PM, JF Tremblay  
wrote:
> Thanks for checking. Changing the IAID might indeed be a good way to 
> implement the “reset privacy” button. Not sure if this should be added to any 
> specifications and which ones. Is this just a regional regulatory 
> requirement? Looks like there isn’t any action for the IETF to take here. 

The DHC working group could reasonably document this as a profile.   Or v6ops.  
 It's apparently non-obvious or nobody would have asked about it, so 
documenting it might be worthwhile.   I think it would be better to do this in 
IETF than in Cablelabs or BBF because it's applicable to both.

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

Re: [homenet] Orchestration of renumbering

[JF Tremblay]

> On Mar 25, 2015, at 2:17 PM, STARK, BARBARA H  wrote:
> 
>> Yup.   Are you aware of similar issues with changing the IAID?   If the ISP 
>> has a
>> limit to how many prefixes can be assigned on a particular customer port,
>> that could cause issues, but if it's a supported feature as it would be in
>> Mikael's case, I think it should be OK.   Do you know the details of what was
>> causing the issue?
> 
> I don't remember the details. I looked at BBF TR-124, to see if there was 
> something similar there, and there wasn't. Then I looked at eRouter specs, 
> and did see that they are specifically re-iterating the requirement for 
> persistence. So maybe it came from the cable companies. Which could explain 
> why my memory of details is so fuzzy.

Yes, it’s very probably coming from the cable side. The first generations of 
cable modems and eRouters firmware sometimes used non-persistent DUID-LLTs 
changing at each reboot. We had also seen it from early “retail” CPEs.  It was 
annoying enough that the persistence requirement was reiterated in some 
documents.

> The TR-124 requirements are used by DSL providers for the CE routers they 
> procure/provide, and aren't expected to apply to "retail" CE routers. The 
> fact that this IAID requirement didn't make it into RFC 7084 leads me to 
> believe that the behavior of retail CE routers wrt IAID is a "don't care”.

Thanks for checking. Changing the IAID might indeed be a good way to implement 
the “reset privacy” button. Not sure if this should be added to any 
specifications and which ones. Is this just a regional regulatory requirement? 
Looks like there isn’t any action for the IETF to take here. 

JF



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

Re: [homenet] Orchestration of renumbering

[STARK, BARBARA H]

> Yup.   Are you aware of similar issues with changing the IAID?   If the ISP 
> has a
> limit to how many prefixes can be assigned on a particular customer port,
> that could cause issues, but if it's a supported feature as it would be in
> Mikael's case, I think it should be OK.   Do you know the details of what was
> causing the issue?

I don't remember the details. I looked at BBF TR-124, to see if there was 
something similar there, and there wasn't. Then I looked at eRouter specs, and 
did see that they are specifically re-iterating the requirement for 
persistence. So maybe it came from the cable companies. Which could explain why 
my memory of details is so fuzzy.

As for IAID, TR-124 says:
"The RG IAID value in DHCPv4 and DHCPv6 MUST be a 32 bit number encoded in 
network byte order. In cases where the RG is functioning with a single DHCP 
client identity, it MUST use value 1 for IAID for all DHCP interactions. IAID 
is defined in IETF RFC 3315.
In cases where the RG is functioning with multiple DHCP client identities, the 
values of IAID have to start at 1 for the first identity and be incremented for 
each subsequent identity. The RG's mapping of IAID to its physical aspects or 
logical configuration SHOULD be as non-volatile as possible. For example, the 
RG MAY use IAID value 1 for the first physical interface and value 2 for the 
second. Alternatively, the RG MAY use IAID value 1 for the virtual circuit 
corresponding to the first connection object in the data model and value 2 for 
the second connection object in the data model."

The TR-124 requirements are used by DSL providers for the CE routers they 
procure/provide, and aren't expected to apply to "retail" CE routers. The fact 
that this IAID requirement didn't make it into RFC 7084 leads me to believe 
that the behavior of retail CE routers wrt IAID is a "don't care".
Barbara

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

Re: [homenet] actual requirements for standardization of an ietf protocol?

[Brian E Carpenter]

Regards
   Brian Carpenter
   http://orcid.org/-0001-7924-6182



On 26/03/2015 05:37, Juliusz Chroboczek wrote:
>> The yak we are shaving here, is whether two inter-operable implementations
>> leveraging the same mit-licensed source code base (as in the base babeld
>> daemon and the quagga implementation) are acceptable to this wg.
> 
> Dave,
> 
> Alia is right -- there do not at the current time exist two independent
> implementations of Babel.
> 
> We can argue about whether that is a reasonable requirement, but we cannot
> argue about the above, which is a fact.

But she also said, or rather logically implied, that if there was a
babel WG it could decide that two strictly independent implementations
were *not* required for Proposed Standard. Of course the AD and the IESG
would have to agree, but it is perfectly allowed by the current IETF rules.

BTW there is also no rule that WGs must hold meetings. Reaching rough consensus
on the WG list is necessary and sufficient under the rules. It's rare
but entirely possible.

Brian

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

Re: [homenet] renumbering RFC router renumbering

[Brian E Carpenter]

Regards
   Brian Carpenter
   http://orcid.org/-0001-7924-6182



On 26/03/2015 05:31, Alexandru Petrescu wrote:
> Le 24/03/2015 21:01, Brian E Carpenter a écrit :
>> On 25/03/2015 08:47, JF Tremblay wrote:
>>>
 On Mar 24, 2015, at 2:00 PM, Brian E Carpenter
  wrote:

 [...] Make-before-break renumbering (a.k.a. planned renumbering)
 is preferable but we can't rely on it. (I also try to never
 forget Fred Baker's observation that there is no such thing as
 renumbering: there is only numbering.)
>>>
>>> Any reference for reading (on Fred’s principle)?
>>
>> I'm not aware of a written version; it's something I've heard him
>> say more than once. Of course there is RFC 4192, but it isn't in
>> that.
> 
> Not sure what the question was but there is a stds track RFC in the 2000s 
> about IPv6 router renumbering, authored at Fermilab IIRC.

You mean RFC 2894, I think.

As is written in RFC 5887:
  "An ICMPv6 extension to allow router renumbering for IPv6 is specified
   in [RFC2894], but there appears to be little experience with it.  It
   is not mentioned as a useful mechanism by [RFC4192]."

 Brian

> 
> That has a notion of difference between numbering and renumbering.
> 
> Numbering is the initial assignment of prefixes on links.  Presumably a 
> manual operation.
> 
> Re-numbering is propagation of tuples [existing prefix, new prefix] with RAs 
> messages between routers.
> 
> This technique was used by other protocols such as Hierarchical Mobile IPv6 
> which is an RFC as well, although experimental IIRC.
> 
> This of course brings the question of what is renumbering.
> 
> Alex
> 
> 
>>
>> Brian
>>>
 [...] However, Dave Taht told us recently that renumbering *is*
 currently broken, and I'd like to see his list of issues. For
 now, here are the issues that I see:
>>>
>>> I’ll let Dave answer for himself, but my personal experience at
>>> home currently is that it breaks quite often. As soon as the home
>>> network gets renumbered, new RAs are flooded, but no RAs are sent
>>> to de-prefer the current prefix (as specified in RFC7084 L-13).
>>> I’ve seen this happen both with 6RD and in native, with two home
>>> router vendors. I usually flap my link physically to flush old
>>> addresses.
>>>
>>> Btw, I didn’t raise this morning, but I believe smooth renumbering
>>> from an ISP is possible, at least for cable ISPs (costly, but
>>> possible). This requires support for multiple concurrent prefix
>>> delegations on home routers, which I haven’t seen yet in the wild.
>>> This requirement isn’t explicitly mentioned in RFC7084, only
>>> indirectly through the support for DHCPv6-PD (WPD-1).
>>>
>>> So on the short term, proper implementation of RFC7084 L-13 is
>>> required for smoother unplanned renumbering. For smooth planned
>>> renumbering, support for multiple concurrent PDs is required. It’s
>>> too bad that the homenet architecture doc (RFC7368 section 3.4.1)
>>> does not even mentions this possibility.
>>>
>>> JF
>>>
>>>
>>>
>>>
>>>
>>
>> ___ 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] Orchestration of renumbering

[Ted Lemon]

On Mar 25, 2015, at 1:27 PM, STARK, BARBARA H  wrote:
> FYI. RFC 7084 has the following:
> 
>   W-5:  The IPv6 CE router MUST use a persistent DHCP Unique Identifier
> (DUID) for DHCPv6 messages.  The DUID MUST NOT change between
> network-interface resets or IPv6 CE router reboots.
> 
> This requirement exists because CE routers that changed their DUIDs 
> experienced issues in certain access architectures.

Yup.   Are you aware of similar issues with changing the IAID?   If the ISP has 
a limit to how many prefixes can be assigned on a particular customer port, 
that could cause issues, but if it's a supported feature as it would be in 
Mikael's case, I think it should be OK.   Do you know the details of what was 
causing the issue?

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

Re: [homenet] Orchestration of renumbering

[Brian E Carpenter]

On 26/03/2015 05:31, Ian Farrer wrote:
> Hi,
> 
>>
>> Actually, why would the customer trigger this? Is there a good use case for 
>> this? In my mind, this is purely triggered from the ISP side, when a network 
>> event is planned to happen.
> 
> In some countries (e.g. Germany), operators provide customer’s with the 
> ability to request a change of IP address via a reset button in the web 
> interface of the HGW. This is based on privacy requirements (which seem 
> dated, but exist).

But presumably, that is only a *request* from the CPE side - the real
action is started by the provider edge.

   Brian

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

Re: [homenet] Orchestration of renumbering

[STARK, BARBARA H]

> >> Wasn't aware of that need. One way to make this happen would be for
> the CPE to reset its DUID. But it's no longer smooth renumbering, the prefix
> will simply change. In this case however, this is a user-triggered action, so
> immediate renumbering might be acceptable. Support for RFC7084 L-13
> would be desirable.
> > Ideally the DHCP client generates a new DUID and does not send the old
> DUID.   This allows for graceful renumbering, since the old prefix is still 
> valid
> until it expires.
> 
> Ideally it could use the same DUID and just switch to a different IAID for its
> IA_PD or even keep asking for two IA_PDs with different IAIDs at the same
> time.

FYI. RFC 7084 has the following:

   W-5:  The IPv6 CE router MUST use a persistent DHCP Unique Identifier
 (DUID) for DHCPv6 messages.  The DUID MUST NOT change between
 network-interface resets or IPv6 CE router reboots.

This requirement exists because CE routers that changed their DUIDs experienced 
issues in certain access architectures.
Barbara

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

Re: [homenet] Orchestration of renumbering

[Ted Lemon]

On Mar 25, 2015, at 12:46 PM, Steven Barth  wrote:
> Ideally it could use the same DUID and just switch to a different IAID for 
> its IA_PD or even keep asking for two IA_PDs with different IAIDs at the same 
> time.

Right, sorry, I misspoke.   Thanks for the correction!   :)

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

Re: [homenet] Orchestration of renumbering

[Timothy Winters]

Hello,

> On Mar 25, 2015, at 12:37 PM, JF Tremblay 
>  wrote:
> 
> 
>> On Mar 25, 2015, at 11:26 AM, Timothy Winters  wrote:
>> 
>> Hi,
>>  For the IPv6 Ready/UNH-IOL testing that we have done, both an 
>> Interoperability and Conformance, there is a test  makes sure a Router 
>> supports getting multiple IA_PDs for Prefix Change.
> 
> Thanks Tim. 
> 
> Two questions: 
> 1. Can you share any data on how often this requirement was met or not? (like 
> a % of tested routers)
> 2. Do you also test for L-13? And is that one usually met?
Currently we have about 15 to 20 implementations at the IOL that are trying to 
meet the 7084 Requirements, including L-13.   Most routers address issues when 
they are made aware of the problem.
> 
> JF
> 
> 
> 
> 
> 

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

Re: [homenet] Orchestration of renumbering

[Steven Barth]

On 25.03.2015 18:43, Ted Lemon wrote:

On Mar 25, 2015, at 11:35 AM, JF Tremblay  
wrote:

Wasn’t aware of that need. One way to make this happen would be for the CPE to 
reset its DUID. But it’s no longer smooth renumbering, the prefix will simply 
change. In this case however, this is a user-triggered action, so immediate 
renumbering might be acceptable. Support for RFC7084 L-13 would be desirable.

Ideally the DHCP client generates a new DUID and does not send the old DUID.   
This allows for graceful renumbering, since the old prefix is still valid until 
it expires.


Ideally it could use the same DUID and just switch to a different IAID 
for its IA_PD or even keep asking for two IA_PDs with different IAIDs at 
the same time.



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

Re: [homenet] Orchestration of renumbering

[Ted Lemon]

On Mar 25, 2015, at 11:35 AM, JF Tremblay  
wrote:
> Wasn’t aware of that need. One way to make this happen would be for the CPE 
> to reset its DUID. But it’s no longer smooth renumbering, the prefix will 
> simply change. In this case however, this is a user-triggered action, so 
> immediate renumbering might be acceptable. Support for RFC7084 L-13 would be 
> desirable. 

Ideally the DHCP client generates a new DUID and does not send the old DUID.   
This allows for graceful renumbering, since the old prefix is still valid until 
it expires.

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

Re: [homenet] actual requirements for standardization of an ietf protocol?

[Juliusz Chroboczek]

> The yak we are shaving here, is whether two inter-operable implementations
> leveraging the same mit-licensed source code base (as in the base babeld
> daemon and the quagga implementation) are acceptable to this wg.

Dave,

Alia is right -- there do not at the current time exist two independent
implementations of Babel.

We can argue about whether that is a reasonable requirement, but we cannot
argue about the above, which is a fact.

-- Juliusz

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

Re: [homenet] Orchestration of renumbering

[JF Tremblay]

> On Mar 25, 2015, at 11:26 AM, Timothy Winters  wrote:
> 
> Hi,
>   For the IPv6 Ready/UNH-IOL testing that we have done, both an 
> Interoperability and Conformance, there is a test  makes sure a Router 
> supports getting multiple IA_PDs for Prefix Change.

Thanks Tim. 

Two questions: 
1. Can you share any data on how often this requirement was met or not? (like a 
% of tested routers)
2. Do you also test for L-13? And is that one usually met?

JF





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

Re: [homenet] Orchestration of renumbering

[JF Tremblay]

> On Mar 25, 2015, at 11:15 AM, Mikael Abrahamsson  wrote:
> 
>> Actually, why would the customer trigger this? Is there a good use case for 
>> this? In my mind, this is purely triggered from the ISP side, when a network 
>> event is planned to happen.
> Because some customers feel that changing addresses is a privacy thing. They 
> might want their ISP to provide a CPE with a button that says "change home 
> prefix now”.

Wasn’t aware of that need. One way to make this happen would be for the CPE to 
reset its DUID. But it’s no longer smooth renumbering, the prefix will simply 
change. In this case however, this is a user-triggered action, so immediate 
renumbering might be acceptable. Support for RFC7084 L-13 would be desirable. 

> How does it "get" PD2? This is what I don't understand. You just all of a 
> sudden next time the DHCPv6-PD communication happens, send two prefixes and 
> then the client will accept these and start using them? The home gateway 
> doesn't actually have to ask for it, you can just send it a bunch of prefixes?

You just configure it in the DHCPv6 server, usually through a script. Same for 
changing lease lifetime values. Ops people do this on a regular basis. 

JF



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

Re: [homenet] renumbering RFC router renumbering

[Alexandru Petrescu]

Le 24/03/2015 21:01, Brian E Carpenter a écrit :

On 25/03/2015 08:47, JF Tremblay wrote:



On Mar 24, 2015, at 2:00 PM, Brian E Carpenter
 wrote:

[...] Make-before-break renumbering (a.k.a. planned renumbering)
is preferable but we can't rely on it. (I also try to never
forget Fred Baker's observation that there is no such thing as
renumbering: there is only numbering.)


Any reference for reading (on Fred’s principle)?


I'm not aware of a written version; it's something I've heard him
say more than once. Of course there is RFC 4192, but it isn't in
that.


Not sure what the question was but there is a stds track RFC in the 
2000s about IPv6 router renumbering, authored at Fermilab IIRC.


That has a notion of difference between numbering and renumbering.

Numbering is the initial assignment of prefixes on links.  Presumably a 
manual operation.


Re-numbering is propagation of tuples [existing prefix, new prefix] with 
RAs messages between routers.


This technique was used by other protocols such as Hierarchical Mobile 
IPv6 which is an RFC as well, although experimental IIRC.


This of course brings the question of what is renumbering.

Alex




Brian



[...] However, Dave Taht told us recently that renumbering *is*
currently broken, and I'd like to see his list of issues. For
now, here are the issues that I see:


I’ll let Dave answer for himself, but my personal experience at
home currently is that it breaks quite often. As soon as the home
network gets renumbered, new RAs are flooded, but no RAs are sent
to de-prefer the current prefix (as specified in RFC7084 L-13).
I’ve seen this happen both with 6RD and in native, with two home
router vendors. I usually flap my link physically to flush old
addresses.

Btw, I didn’t raise this morning, but I believe smooth renumbering
from an ISP is possible, at least for cable ISPs (costly, but
possible). This requires support for multiple concurrent prefix
delegations on home routers, which I haven’t seen yet in the wild.
This requirement isn’t explicitly mentioned in RFC7084, only
indirectly through the support for DHCPv6-PD (WPD-1).

So on the short term, proper implementation of RFC7084 L-13 is
required for smoother unplanned renumbering. For smooth planned
renumbering, support for multiple concurrent PDs is required. It’s
too bad that the homenet architecture doc (RFC7368 section 3.4.1)
does not even mentions this possibility.

JF







___ 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] Orchestration of renumbering

[Ian Farrer]

Hi,

> 
> Actually, why would the customer trigger this? Is there a good use case for 
> this? In my mind, this is purely triggered from the ISP side, when a network 
> event is planned to happen.

In some countries (e.g. Germany), operators provide customer’s with the ability 
to request a change of IP address via a reset button in the web interface of 
the HGW. This is based on privacy requirements (which seem dated, but exist).

Ian


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

Re: [homenet] Orchestration of renumbering

[Timothy Winters]

Hi,
For the IPv6 Ready/UNH-IOL testing that we have done, both an 
Interoperability and Conformance, there is a test  makes sure a Router supports 
getting multiple IA_PDs for Prefix Change.

~Tim

> On Mar 25, 2015, at 12:23 PM, Steven Barth  wrote:
> 
> 
> 
> 
> >How does it "get" PD2? This is what I don't understand. You just all of
> >a 
> >sudden next time the DHCPv6-PD communication happens, send two prefixes
> >
> >and then the client will accept these and start using them? The home 
> >gateway doesn't actually have to ask for it, you can just send it a
> >bunch
> 
> In general the cpe asks for an "identity association for prefix delegation" 
> (ia_pd). The server can include as many prefixes with individual lifetimes 
> into that ia_pd as it likes.
> 
> Taking 6204 / 7084 into account the cpe even must support dynamic 
> reconfiguration meaning the server can at any point in time tell the client 
> to renew and doesn't need to wait for a renew.
> 
> That all of course is given compliant cpes...
> 
> 
> Cheers, 
> 
> Steven
> 
> ___
> 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] Mesh networks in the homenet

[Alexandru Petrescu]

Le 24/03/2015 19:01, Juliusz Chroboczek a écrit :

Before we lose this, let it be noted that we seemed to have arrived
at "no" for an answer to whether we want to deal with
non-transitive networks, *as part of this particular routing
protocol discussion*.


This is what the protocol comparison draft has to say on the
subject:

We believe that IBSS may be out of scope for Homenet, but we expect
that people will attempt to use the Homenet protocols in IBSS mode,
whether we like it or not.


Well, you can put IBSS out of scope for homenet WG, but nobody can stop
one to set an IBSS mode in a home network.

This is a confusion about the use of the term 'home networking and
homenet WG'.


Without special ND handling, Hidden nodes will fail DAD, and you
can't expect to get a mac address for a node you don't get
multicast to.


I agree.  If we assume unmodified clients, then IBSS is only suitable
for router-to-router links.  However, I think that Homenet needs a
killer feature, and almost-zeroconf router-to-router wireless links
might be it.


There are a few such killer features but they dont seem to be considered
in homenet WG.

To find one it is very easy: express a problem you have encountered.

Buy a modern home device bring it home and tell what was the difficulty
in setting it up.  There are many simple problems immediately exposed:
how is IPv6 running (is it NAT? is it PD? is it ULA?  is it running DHCP?).

Ask your DSL operator what IPv6 and how.  In France there are now two
IPv6-enabled DSL operators for the user lambda (not professional) and
you'll see how they need some feature.  For example Free IPv6 DSL only
allows setting routes manually by filling in forms in a webpage -
automate that.  Orange IPv6 DSL is nascent yesterday - what are the
problems there?


(Now I happen to believe that if Homenet is successful, we will get
modified clients -- think Android -- but I realise that this opinion
does not necessarily reflect the consensus of this group.)


I *don't* think meshes are out of scope for homenet.  I do think
meshes need a mesh routing protocol.


I disagree.  If you accept that a small mesh is a cheap and
convenient way to establish a router-to-router link, then you'll want
to avoid the tricky issues that come with running multiple routing
protocols (bidirectional redistribution at two distinct points within
the network, oh boy).


Multiple routing protocols is inevitable IMHO.  To deal with it is like
dealing with OSPF and BGP - make them talk to each other.


(But then, I'm pretty much bound to disagree.  The desire to have a
single routing protocol that you let loose on a highly heterogeneous
network and it just works is the main driver behind Babel.)


A single routing protocol is a good goal to state at WG meeting decision
time.  But it often leads to actually new protocol which will be the
one.  We've seen that recently with RPL - that's the one.  There is even
a set of requirements for it in the home networks (RFC).

Should we enumerate all routing protocols which are 'the one'?


we would be talking about AP / BSS, not ad-hoc / IBSS [...]
Massively reduced marginal links (because when you start losing
beacons between AP and Client, you'll be deassociated.)


I strongly disagree.  By default, the Linux Intel driver will
perform recalibration after it misses 5 beacons in a row.  You can
have a perfectly functional yet clearly marginal link in AP/STA
mode.


Maybe yes, with that particular driver.

Alex



-- 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] Orchestration of renumbering

[Steven Barth]

>How does it "get" PD2? This is what I don't understand. You just all of
>a 
>sudden next time the DHCPv6-PD communication happens, send two prefixes
>
>and then the client will accept these and start using them? The home 
>gateway doesn't actually have to ask for it, you can just send it a
>bunch

In general the cpe asks for an "identity association for prefix delegation" 
(ia_pd). The server can include as many prefixes with individual lifetimes into 
that ia_pd as it likes.

Taking 6204 / 7084 into account the cpe even must support dynamic 
reconfiguration meaning the server can at any point in time tell the client to 
renew and doesn't need to wait for a renew.

That all of course is given compliant cpes...


Cheers, 

Steven

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

Re: [homenet] Orchestration of renumbering

[Mikael Abrahamsson]

On Wed, 25 Mar 2015, JF Tremblay wrote:

Actually, why would the customer trigger this? Is there a good use case 
for this? In my mind, this is purely triggered from the ISP side, when a 
network event is planned to happen.


Because some customers feel that changing addresses is a privacy thing. 
They might want their ISP to provide a CPE with a button that says "change 
home prefix now".



Here’s a cable-oriented scenario (sorry, this is my background). In the cable 
world, providing a perfectly stable prefix for home customers is quite 
challenging, because the underlying physical network changes on a regular basis 
to accommodate physical network growth and changes (usually once or twice a 
year per user). It’s possible to provide stable prefixes, but it involves 
significant engineering and operational effort (hence a cost).

An alternative for cable operators is to provide smooth IPv6 renumbering. 
Here’s how it could work. This is basically a simpler flavor of RFC4192.
1. The customer gets PD1 from CMTS A. (a /56 out a /40 for example). Stable 
operation.
2. A week in advance of a network change, a move from CMTS A to CMTS B, the 
customer gets a reduced DHCPv6 lease time to 24h.
3. 24h before the change, the client gets two prefixes PD1 and PD2, out of A 
and B /40s respectively. PD1 has a preferred lifetime of 0 and a valid lifetime 
of 24h.


How does it "get" PD2? This is what I don't understand. You just all of a 
sudden next time the DHCPv6-PD communication happens, send two prefixes 
and then the client will accept these and start using them? The home 
gateway doesn't actually have to ask for it, you can just send it a bunch 
of prefixes?


--
Mikael Abrahamssonemail: swm...@swm.pp.se___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Mesh networks in the homenet

[Alexandru Petrescu]

Le 24/03/2015 17:49, David Lamparter a écrit :

On Tue, Mar 24, 2015 at 05:28:05PM -0500, Alexandru Petrescu wrote:

Le 24/03/2015 17:19, David Lamparter a écrit :

Before we lose this, let it be noted that we seemed to have
arrived at "no" for an answer to whether we want to deal with
non-transitive networks, *as part of this particular routing
protocol discussion*.

If I'm misrepresenting the outcome from today's meeting, someone
please correct me.


That transitiveness issue is from the fact that their routers only
have 1 interface.


I don't follow. If each of the routers in the A-B-C situation has a
wired segment attached to them, it's still A-C intransitive, but
they each have 2 interfaces?


Err, no.  It's an A-B-C situation where each (even B) has 1 interface,
and all are in an IBSS.  This is the situation described in that draft.


Are there 1-interface routers in homenet?


In an 802.11 IBSS, I would assume yes.


Well IBSS is not made to have 1-interface routers on them, so this
(1-interface routers) is not really good to do, in my personal oppinion.

IBSS is made to have 1-interface Hosts on it, not routers.

Remark this is my IMHO and a number of other people disagree with this.

I know.

I just tell that you can build a very good ad-hoc network without an AP
and with 2-interface routers.  At that point there is no hidden-terminal
problem.


I *don't* think meshes are out of scope for homenet.  I do think
meshes need a mesh routing protocol.  But pulling this into the
current discussion seems to generate nothing but waste heat.


We dont have a definition of what a mesh is.  Saying mesh is
inviting people from RoLL and MANET WGs to argue.

However, I'd doubt a homenet is a mesh in their sense.


Sorry - replace "mesh" with "network segment with intransitive
reachability" in my mail.


Ok.  I'd substitute network for mesh altogether.


(And I'm not applying the concept to a homenet as a whole, I see it
as an attribute of a particular set of links / interface types.)


Well, I dont.

A mesh is a network and vice-versa.


As a consequence, when we talk about 802.11, we would be talking
about AP / BSS, not ad-hoc / IBSS.


Yes and no.

Yes, at home most deployments are in AP mode.

But no in that still at home the WiFi landscape has recently
become reacher than the old dichotomy AP-mode vs adhoc-mode.  E.g.
the 802.11ac and ad products feature direct AP to AP communication
for range extension, or streaming from a tablet to a TV set, or a
LED projector switching between being an AP itself or being a
Client to another AP.


I'll have to look at these in detail, but they sound like individual
links that would be treated as P2P in the routing protocol.


I agree, although I dont understand what you mean by P2P.

Peer-to-peer networks is a great term used by DSL boxes and enhanced
Blueray players to download content from P2P platforms.

Peer-to-peer is also a great term used by the RPL protocol to tell a
node talks directly to another RPL node, instead of up-and-down a
Directed Acyclic Graph.

Point-to-point links are those which only have two IP ends on them, like
a cellular link of a smartphone, or the uplink of a DSL box.

A AP to AP wireless link could be a point-to-point link, but I dont
think point-to-point protocols are used on these links.  The netgear
802.11ac AP to AP communication (see its user manual) is not necessarily
a point-to-point link.  I _suppose_ that link is a WiFi link like any
other (i.e. not point-to-point link).



(In the tablet to TV set case, I guess routing wouldn't be involved
at all?  Strays into the "is everything a router?" question,
though.)


Sure it should.

In a typical homenet you have a growing number of these apparently
specialized links.  You have this tablet-to-TV but also 802.15.4 smart
light control, and remotely controlled window shades, alarms, smartbody 
to smartphones, smartgrid control, and more.  Each of these works ok 
isolated in itself.  When you want to link them together only IP works 
for each.  And only a notion of IP routing can find paths through such a 
maze.  Actually it's such complex that I gave up completely considering 
it, it's craziness.



No hidden node problem.  No intransitive reachability.
Massively reduced marginal links (because when you start losing
beacons between AP and Client, you'll be deassociated.)


Tinkering about this.


Tinker loudly, into your keyboard, onto a mail ;)


Overall it may boil down to have IP running on each of these links, a
routing protocol and an address and prefix assignment functionality.

Alex




-David




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

Re: [homenet] actual requirements for standardization of an ietf protocol?

[Dave Taht]

On Wed, Mar 25, 2015 at 8:58 AM, Alia Atlas  wrote:
> In the Routing Area, it depends upon the WG as to whether 2 interoperable
> implementations are required.   This is always the case in,  for example ,
> IDR.  For a new routing protocol,  I think it would be appropriate to be
> comfortable that others can implement it and it works well.

The yak we are shaving here, is whether two inter-operable implementations
leveraging the same mit-licensed source code base (as in the base babeld daemon
and the quagga implementation) are acceptable to this wg.

>
> Regards,
> Alia
>
> On Mar 25, 2015 7:43 AM, "Brian E Carpenter" 
> wrote:
>>
>> > 1) I don't know where the "2 separate implementation" concept is
>> > embedded formally in the ietf structures for approval.
>>
>> It isn't, for Proposed Standard status, although historically the
>> Routing Area has been tougher than the rest of the IETF because of
>> reasonable concern that a faulty routing protocol can produce more
>> horrible failure modes than pretty much anything else.
>>
>> http://tools.ietf.org/html/rfc4794 may clarify a bit.
>>
>> For advancement to Internet Standard there is a requirement
>> for 2 implementations but that is not germane to the current
>> discussion. (http://tools.ietf.org/html/rfc6410)
>>
>> Sigh. It's embarassing how baroque the IETF process documents
>> have become, but it would be a lot of uninspiring work to
>> clean them up. That's why I've been maintaining this page for
>> a few years now: http://www.ietf.org/about/process-docs.html
>> (And yes, I'm aware it's overdue for an update.)
>>
>>   Brian
>>
>> ___
>> homenet mailing list
>> homenet@ietf.org
>> https://www.ietf.org/mailman/listinfo/homenet



-- 
Dave Täht
Let's make wifi fast, less jittery and reliable again!

https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb

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

Re: [homenet] actual requirements for standardization of an ietf protocol?

[Alia Atlas]

In the Routing Area, it depends upon the WG as to whether 2 interoperable
implementations are required.   This is always the case in,  for example ,
IDR.  For a new routing protocol,  I think it would be appropriate to be
comfortable that others can implement it and it works well.

Regards,
Alia
On Mar 25, 2015 7:43 AM, "Brian E Carpenter" 
wrote:

> > 1) I don't know where the "2 separate implementation" concept is
> > embedded formally in the ietf structures for approval.
>
> It isn't, for Proposed Standard status, although historically the
> Routing Area has been tougher than the rest of the IETF because of
> reasonable concern that a faulty routing protocol can produce more
> horrible failure modes than pretty much anything else.
>
> http://tools.ietf.org/html/rfc4794 may clarify a bit.
>
> For advancement to Internet Standard there is a requirement
> for 2 implementations but that is not germane to the current
> discussion. (http://tools.ietf.org/html/rfc6410)
>
> Sigh. It's embarassing how baroque the IETF process documents
> have become, but it would be a lot of uninspiring work to
> clean them up. That's why I've been maintaining this page for
> a few years now: http://www.ietf.org/about/process-docs.html
> (And yes, I'm aware it's overdue for an update.)
>
>   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

Re: [homenet] Orchestration of renumbering

[JF Tremblay]

Thanks for the pointer to draft-baker-6renum-oss-renumbering, Tim. It’s true 
that renumbering is only a sequence of numbering actions. 

> On Mar 25, 2015, at 9:20 AM, Mikael Abrahamsson  wrote:

> At this time, I do not understand the DHCPv6-PD state machinery to enable 
> temporal overlap of prefixes so one can achieve a graceful renumbering event. 
> I wrote this text a while back but never sent it to DHC. Could someone please 
> help by explaining how to do this temporal overlap using DHCPv6-PD?

I can take a shot at this. I’ve done it in a production-like lab with cable 
equipment. I believe it was with an experimental OpenWRT or D-Link that 
supported dual-PD.  

> Now, after a while, the customer decides he wants to change the addressing 
> space, but he wants to do this gracefully, basically along the lines of 
> RFC4192. So for a certain amount of time, he wants to have two PDs,
> and these need to be distinct.

This is where your example stops working. At “the customer decides”. IMHO 
there’s no way to make this work purely as a customer-triggered sequence of 
event. 

Actually, why would the customer trigger this? Is there a good use case for 
this? In my mind, this is purely triggered from the ISP side, when a network 
event is planned to happen.

Here’s a cable-oriented scenario (sorry, this is my background). In the cable 
world, providing a perfectly stable prefix for home customers is quite 
challenging, because the underlying physical network changes on a regular basis 
to accommodate physical network growth and changes (usually once or twice a 
year per user). It’s possible to provide stable prefixes, but it involves 
significant engineering and operational effort (hence a cost). 

An alternative for cable operators is to provide smooth IPv6 renumbering. 
Here’s how it could work. This is basically a simpler flavor of RFC4192. 
1. The customer gets PD1 from CMTS A. (a /56 out a /40 for example). Stable 
operation. 
2. A week in advance of a network change, a move from CMTS A to CMTS B, the 
customer gets a reduced DHCPv6 lease time to 24h. 
3. 24h before the change, the client gets two prefixes PD1 and PD2, out of A 
and B /40s respectively. PD1 has a preferred lifetime of 0 and a valid lifetime 
of 24h.
At this point, clients start using PD2 gradually as leases expire and get 
renewed. The number of disjoint routes in the ISP network raises (deaggregation 
happens)
4. The change is made overnight. At this point, all clients should already be 
using PD2.
5. Most clients will redo DHCPv6 (depending if they saw a link-down event, 
ymmv). 
PD2 is used everywhere and get re-aggregated in the original /40. 
PD1 should no longer be used, but is still routed (through B) and 
deaggregated. 
6. PD1 is removed on the DHCPv6 server and lease time restored to its original 
value. 
After another 24h, PD1 is no longer present in home networks, no longer 
routed and no deaggregation remains. 

The only missing part to make this happen is for home routers to support 
multiple PDs. The specific DHCPv6 servers and CMTSes implementations I used 
already supported multi-PD years ago. The big advantage of this for cable 
operators is to keep user routes aggregated.

JF




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

Re: [homenet] Babel specification quality [was: Dynamically computed metrics...]

[Juliusz Chroboczek]

>> It would be extremely helpful if you could take the time to explain to me
>> what it is exactly that you found confusing in RFC 6126.

> I was not speaking for myself, but reflecting the statements made at the
> working group meeting

I see, thanks for your answer.

-- Juliusz

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

Re: [homenet] Orchestration of renumbering

[Mikael Abrahamsson]

On Wed, 25 Mar 2015, Brian E Carpenter wrote:

2. We assume that a prefix delegation or withdrawal from above by 
DHCPv6-PD will trigger the appropriate actions by 
draft-ietf-homenet-prefix-assignment. But I can't tell from the draft 
how that happens. Presumably some process in the relevant CPE does it.


At this time, I do not understand the DHCPv6-PD state machinery to enable 
temporal overlap of prefixes so one can achieve a graceful renumbering 
event. I wrote this text a while back but never sent it to DHC. Could 
someone please help by explaining how to do this temporal overlap using 
DHCPv6-PD?



Hi,

For several reasons, there is a need to have overlapping IPv6 addressing 
space, both delegated to devices (PD) or addresses (IA_NA), when doing 
graceful renumbering. Let's take the following network:


ISP - CPE - HOST1

The CPE requests a prefix using PD, and is delegated 
2001:DB8:100:100::/56. it then configures 2001:DB8:100:101::X/64 on its 
LAN interface. HOST1 uses DHCPv6 and asks for IA_NA and is assigned 
2001:DB8:100:101::Y/128

IA_NA by CPE.

Now, after a while, the customer decides he wants to change the addressing 
space, but he wants to do this gracefully, basically along the lines of 
RFC4192. So for a certain amount of time, he wants to have two PDs,

and these need to be distinct.

What would need to happen, is that the customer needs to signal to the ISP 
that he needs a second PD, that this should be distinct from the first 
one, and that he wants to keep both for a certain amount of time, but
understands that the initial PD is not going to be refreshed/extended in 
time and will be removed.


What needs to happen is that the CPE needs to get a new /60, it needs to 
allocate a /64 out of this in addition to the existing /64, HOST1 needs to 
understand that it should ask for a new IA_NA and that it should stop
using the existing IA_NA for new connections. I don't know if this 
automatically happens if the RA for the old prefix shows up with a lower 
preferred timer set.


So there are two issues here (I guess):

How can the CPE indicate that it doesn't want the original prefix any 
more, request a new one, and let old one expire after a period of overlap?


How will HOST1 understand that it needs to request a new IA_NA while still 
keeping the old IA_NA until it expires, and de-preferring the old IA_NA in 
the meantime?


Also, how can the ISP initiate this kind of graceful renumbering event? 
The only way I can think of would be some kind of intent flag to say "the 
lease time of this resource will not be extended and you should ask for

a new one" or something to that effect.


--
Mikael Abrahamssonemail: swm...@swm.pp.se

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

Re: [homenet] Mesh networks in the homenet

[Ted Lemon]

On Mar 24, 2015, at 5:19 PM, David Lamparter  wrote:
> As a consequence, when we talk about 802.11, we would be talking about
> AP / BSS, not ad-hoc / IBSS.  No hidden node problem.  No intransitive
> reachability.  Massively reduced marginal links (because when you start
> losing beacons between AP and Client, you'll be deassociated.)

To put it in a single sentence, I think what you are saying is that in a 
homenet, a mesh is treated as a single link, and whatever magic is required to 
make it work is invisible to the routing protocol.

Of course, I should point out that if this is the case, then we have to make 
sure that the routing protocol will be able to use this "link" as transit.   :)

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

Re: [homenet] Dynamically computed metrics in IS-IS are difficult

[Christian Hopps]

On 24 Mar 2015, at 14:32, Juliusz Chroboczek wrote:


Dear all,

At todays meeting, the claim was made (at least twice) that adding
dynamically computed metrics to IS-IS is "just a feature".  I strongly
disagree with this assessment -- it's an open research problem, and
a difficult one at that.


I think Margaret tried to convey that it would not be as simple as 
copying the work from babel, but that we should be able to leverage the 
work already done there.


Any interesting metric (packet loss, delay, etc.) will cause a 
negative
feedback loop, which will lead to oscillations.  In Babel, there are 
three

mechanisms that cope with the oscillations caused by feedback loops:

1. the protocol is loop-avoiding, which means that even when 
oscillations

 happen they don't normally cause packets to be lost;
2. the protocol uses delayed updates, which means that even when a 
metric

 is varying the amount of network traffic remains controlled;
3. the protocol uses a hysteresis mechanism which limits the frequency 
of

 oscillations.


Points 2 and 3 are, I believe, the work we should be able to fairly 
easily leverage.



IS-IS is fundamentally based on the notion that a topology change is
propagated throughout the network in a timely manner and SPF is 
recomputed

by all nodes -- it has no loop-avoidance mechanism other then timely
reconvergence.  If implemented naively, a dynamically computed metric 
will
cause repeated flooding, repeated SPF computation, and repeated 
transient

loops.


In fact much work has been done on this in the routing area. For example 
please see:


https://tools.ietf.org/html/rfc6976

Thanks,
Chris.




I'm sure these issues can be solved, and I'm pretty confident that 
Henning

can tell you how; at any rate, it would be a very interesting research
project.  However, it is a difficult one, and the three techniques 
used in

Babel do not apply directly to a link-state protocol.

-- 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] actual requirements for standardization of an ietf protocol?

[Brian E Carpenter]

> 1) I don't know where the "2 separate implementation" concept is
> embedded formally in the ietf structures for approval.

It isn't, for Proposed Standard status, although historically the
Routing Area has been tougher than the rest of the IETF because of
reasonable concern that a faulty routing protocol can produce more
horrible failure modes than pretty much anything else.

http://tools.ietf.org/html/rfc4794 may clarify a bit.

For advancement to Internet Standard there is a requirement
for 2 implementations but that is not germane to the current
discussion. (http://tools.ietf.org/html/rfc6410)

Sigh. It's embarassing how baroque the IETF process documents
have become, but it would be a lot of uninspiring work to
clean them up. That's why I've been maintaining this page for
a few years now: http://www.ietf.org/about/process-docs.html
(And yes, I'm aware it's overdue for an update.)

  Brian

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

Re: [homenet] rtg-comparison multicast section

[Christian Hopps]

On 22 Mar 2015, at 21:54, David Lamparter wrote:


For the comparison document, this thread is what I would expect to see
for section 11, looking at "backing" for multicast routing instead of
multicast routing itself.


I agree with this. The document should be talking about IS-IS supporting 
a multicast topology, and not using IS-IS as a multicast routing 
protocol.


Thanks,
Chris.



Cheers,


-David


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

Re: [homenet] Orchestration of renumbering

[Tim Chown]

> On 25 Mar 2015, at 02:01, Brian E Carpenter  
> wrote:
> 
> On 25/03/2015 08:47, JF Tremblay wrote:
>> 
>>> On Mar 24, 2015, at 2:00 PM, Brian E Carpenter 
>>>  wrote:
>>> 
>>> [...] Make-before-break
>>> renumbering (a.k.a. planned renumbering) is preferable but we can't
>>> rely on it. (I also try to never forget Fred Baker's observation that
>>> there is no such thing as renumbering: there is only numbering.)
>> 
>> Any reference for reading (on Fred’s principle)?
> 
> I'm not aware of a written version; it's something I've heard him say
> more than once. Of course there is RFC 4192, but it isn't in that.

And it’s very true. A point made several times through 6renum’s lifetime.

For one, it’s in the introduction here:
https://tools.ietf.org/html/draft-baker-6renum-oss-renumbering-00 


Tim

> Brian
>> 
>>> [...] However, Dave Taht told us
>>> recently that renumbering *is* currently broken, and I'd like to see his
>>> list of issues. For now, here are the issues that I see:
>> 
>> I’ll let Dave answer for himself, but my personal experience at home 
>> currently is that it breaks quite often. As soon as the home network gets 
>> renumbered, new RAs are flooded, but no RAs are sent to de-prefer the 
>> current prefix (as specified in RFC7084 L-13). I’ve seen this happen both 
>> with 6RD and in native, with two home router vendors. I usually flap my link 
>> physically to flush old addresses. 
>> 
>> Btw, I didn’t raise this morning, but I believe smooth renumbering from an 
>> ISP is possible, at least for cable ISPs (costly, but possible). This 
>> requires support for multiple concurrent prefix delegations on home routers, 
>> which I haven’t seen yet in the wild. This requirement isn’t explicitly 
>> mentioned in RFC7084, only indirectly through the support for DHCPv6-PD 
>> (WPD-1). 
>> 
>> So on the short term, proper implementation of RFC7084 L-13 is required for 
>> smoother unplanned renumbering. For smooth planned renumbering, support for 
>> multiple concurrent PDs is required. It’s too bad that the homenet 
>> architecture doc (RFC7368 section 3.4.1) does not even mentions this 
>> possibility. 
>> 
>> JF
>> 
>> 
>> 
>> 
>> 
> 
> ___
> 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