Re: [homenet] Support for RFC 7084 on shipping devices...

[Brian E Carpenter]

On 07-Oct-19 22:49, Michael Richardson wrote:
> 
> Mark Smith  wrote:
> > Perhaps ANIMA is an alternative? It has seemed to me that home networks
> > might be just a more specific case of autonomic networks.
> 
> > For example, they've been defining a Generic Autonomic Signalling
> > Protocol (GRASP).
> 
> GRASP has some overlap with HNCP, but HNCP isn't really the issue.
> Homenet has a routing protocol (BABEL).  It was going to be OSPFv3, and we'd
> add the information flooding that HNCP wound up doing into OSPFv3, but that
> "didn't work" and the WG (mysteriously) abandonned that idea.
> 
> ANIMA's GRASP is also not a routing protocol: ANIMA builds an overlap control
> layer with IP over IPsec over IPv6LL tunnels, and runs RPL (RFC6550) as
> the routing protocol for the control plane.  While the resulting ACP shares
> some properties with the desired HOMENET routing goals, it's not the same
> thing at all.

No, it isn't. I didn't have time to reply fully yesterday.

First: when ANIMA was originally chartered, we took care to avoid overlap
and interference with HOMENET. In particular, ANIMA assumes there is some
degree of professional management of the network, which autonomic functions
are expected to enhance and simplify. Also they will probably do things
(like policy-driven decision taking) that are not really expected in
a home network.

Second: GRASP is not competing with HNCP. That's analyzed in
https://tools.ietf.org/html/draft-ietf-anima-grasp-15#appendix-F
(GRASP is an approved draft, stuck waiting for missing references).

Third: If there was a desire to use the ANIMA work for homenets
or unmanaged small office networks, there would be work to do.
As Michael says, we'd need to adapt the autonomic control plane
accordingly. And then some autonomic service agents would need to
be written to fulfill, guess what, the HOMENET requirements
implied by RFC 7368. For example, an agent to perform address
assignment and an agent to configure the dataplane routing protocol.

Regards
   Brian

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

Re: [homenet] Support for RFC 7084 on shipping devices...

[Brian E Carpenter]

On 07-Oct-19 11:34, Mark Smith wrote:
> Perhaps ANIMA is an alternative? It has seemed to me that home networks might 
> be just a more specific case of autonomic networks.

...for professionally managed networks. So there would be new work to do, if we 
wanted to expand the scope.

> 
> For example, they've been defining a Generic Autonomic Signalling Protocol 
> (GRASP).
> 
> https://tools.ietf.org/wg/anima/
> 
> Brian Carpenter has been working on an implementation.
> 
> https://github.com/becarpenter/graspy

Which is plastered with warnings that it's not fit for real-life usage, as a 
prototype written in Python.

   Brian

> 
> On Mon, 7 Oct 2019, 08:41 Ted Lemon,  > wrote:
> 
> On Oct 6, 2019, at 10:58 AM, Ole Troan  > wrote:
>> Are you saying there might be gaps in HNCP? Or things we could do to 
>> make it more deployable?
>> If it's just a matter of running code missing, I'm not sure defining 
>> anything else new in the IETF would help that problem.
> 
> There are definitely missing features from the protocol that I’d like to 
> add.   But I think the fact that the protocol isn’t deployed on a _single_ 
> commercially available router, and is not really usable on OpenWRT by a 
> non-expert, is an indication that there is substantial remaining work to do.  
>  Operations work is not out of scope for IETF; maybe I should have asked this 
> on v6ops.   We have historically said “not our problem,” but I don’t agree 
> that that’s the right answer.   If HNCP had really convincingly solved the 
> problem, we would not be seeing what we are seeing.
> 
>> I know why I haven't implemented HNCP on software I work on... and I 
>> also know that there aren't any very realistic alternatives either.
> 
> Can you say why that is?
> 
>> RA guard isn't applicable in a RFC7084 context. RFC7078 talks about 
>> routing and routers. I.e. what happens at the network layer.
> 
> You mean at the “internet layer,” I assume?
> 
>> If you are talking about what happens at the often integrated bridge CE 
>> devices have, then sure, they could implement RA Guard.
>> But having your additional router sending RAs across the homenet might 
>> not be a particularly good idea anyway.
> 
> Why not?   What would be a better idea?   I don’t mean to say that using 
> RAs in this way is ideal, but what’s the alternative that doesn’t involve the 
> vast complexity of per-host routing?
> 
>> Sounds like you need to set it up as a NAT.
> 
> I really hope you are just making a funny joke here.   But it’s not very 
> funny.   What I want is something that’s operationally simple, not something 
> with lots of moving parts that have to be kept track of.   NATs in particular 
> suck for any UDP-based protocol.
> 
>> I wasn't thinking of doing it exactly like the 6lowpan does it.
>> Regardless I don't see why scaling should be problematic, are you 
>> planning to have millions of rapidly moving hosts on your shared /64 network?
> 
> If you have N devices on a single link on the other side of the router, 
> then when using either RA or a routing protocol, the amount of information 
> you need to propagate to get things working is very small: just a prefix and 
> a router.   If you can’t do that, then the amount of information you need to 
> propagate is at a minimum N units, and possibly K*N, for some not 
> insignificant factor K.
> 
> To be clear, the reason I’m concerned about this is that I’ve looked at 
> implementing it on OpenWRT, and it’s at least roughly doubling the complexity 
> of the work required, even if you can depend on using IPv6.   If you have to 
> use IPv4 on one side, then it’s even more complexity.   And it’s utterly 
> stupid complexity—it adds no value over subnetting.   Why add that to the 
> network?
> 
> This is why I’m asking people if they have knowledge of what is actually 
> deployed.   I think this is the right place to ask, but if you disagree, I’m 
> open to suggestions.
> 
> 
> 
> IETF IPv6 working group mailing list
> i...@ietf.org 
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> 
> 
> 
> ___
> 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] Minutes of today's interim

[Brian E Carpenter]

On 2018-08-22 09:05, Stephen Farrell wrote:
> 
> Hi all,
> 
> I posted minutes at [1]. Comments welcome!

Thanks for the detailed notes.

The github repo URL is wrong. Try 
https://github.com/ietf-homenet-wg/simple-naming

  Brian
 
> Next session is same time (1500 UTC) on Sep 4th.
> 
> Cheers,
> S.
> 
> [1]
> https://datatracker.ietf.org/meeting/interim-2018-homenet-01/materials/minutes-interim-2018-homenet-01-201808211600
> 
> 
> 
> ___
> 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] standard way of configuring homenets

[Brian E Carpenter]

On 25/07/2018 14:59, STARK, BARBARA H wrote:
>  Since homenet is supposed to be about an unmanaged network, 
> and configuration via a management protocol requires somebody who knows what 
> they’re doing, 

Traditionally, yes, but we do actually want to get away from that.
(It's our explicit goal to do that in ANIMA, for which homenets are
out of scope, but we assume that the starting point is a NOC staffed
by people who know what they are doing.)

The idea of capturing a homenet config and saving it for future use
doesn't seem outlandish to me, and using tools developed for
managed networks, but operated robotically instead of manually, doesn't
seem crazy either. But it might be a big effort and a distraction.

   Brian

> it doesn’t fall within my interpretation of the charter.
> Barbara
> 
> From: homenet  On Behalf Of Ted Lemon
> Sent: Tuesday, July 24, 2018 5:57 PM
> To: Michael Richardson 
> Cc: homenet 
> Subject: Re: [homenet] standard way of configuring homenets
> 
> I don't think using HNCP in that particular way is a great plan, but I'm 
> willing to be convinced.   I would hope that this is in charter.
> 
> On Tue, Jul 24, 2018 at 5:48 PM, Michael Richardson 
> mailto:mcr+i...@sandelman.ca>> wrote:
> 
> I very much like the idea of having a standard way to configure homenets.
> There is the YANG/NETCONF method, and I think that we should go in that
> direction.
> 
> A thought I had though could a HOMENET configuration be recorded by
> capturing just HNCP traffic?  Could a network configuration be restored
> by essentially playing back that stuff?  I'm pretty sure that this won't
> work, but the question is... should it?
> 
> Does this work fit into the charter?
> 
> --
> ]   Never tell me the odds! | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works| network architect  [
> ] m...@sandelman.ca  
> http://www.sandelman.ca/
> |   ruby on rails[
> 
> 
> 
> ___
> 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] In-network connectivity and HNCP: IPv6 ULA

[Brian E Carpenter]

Ted,
On 19/07/2018 13:36, Ted Lemon wrote:
> In order for IPv6 to be useful, you need naming to work. We had this
> discussion when I brought this up last year. It should be possible for an
> IPv6-only homenet to work. But if we want homenet to be widely adopted, I
> do not think this is the correct default behavior: 

What "this" do you mean? Switching to ULAs to maintain local
connectivity? What's the surprise? There's no reason there
wouldn't be corresponding  records, is there?

> it violates the
> principle of least surprise. Further, unless you prevent services from
> advertising IPv4 addresses, 

We have a plan for that: draft-ietf-6man-ipv6only-flag-01

Brian

> dropping the IPv4 uplink definitely will cause
> connections to hang.
> 
> On Wed, Jul 18, 2018 at 8:43 PM Juliusz Chroboczek  wrote:
> 
>> During his talk, Ted claimed that he lost all connectivity when his uplink
>> went down.  This should not happen -- HNCP normally maintains an IPv6 ULA
>> that remains stable no matter what happens to DHCPv6 prefix delegations or
>> DHCPv4 leases.  This is described in Section 6.5 of RFC 7788, and it is
>> the default behaviour of hnetd.
>>
>> Either Ted had tweaked the configuration of hnetd (which one should not
>> do -- hnetd does the right thing out of the box), or he was using software
>> that doesn't speak IPv6 or ignores ULAs.  At any rate, HNCP does not have
>> the issue that Ted described.
>>
>> -- 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
> 

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

Re: [homenet] Introduction to draft-ietf-homenet-simple-naming

[Brian E Carpenter]

On 01/06/2018 00:07, David R. Oran wrote:
> On 30 May 2018, at 19:39, Brian E Carpenter wrote:
> 
>> On 31/05/2018 08:53, Juliusz Chroboczek wrote:
>>>> Well, let me invent something. I throw together my network and 
>>>> it
>>>> names the printers as printer1 and printer2. Being a stickler,
>>>> I decide to rename them as Printer 1 and Printer 2. I mess 
>>>> around
>>>> and find a config file somewhere and manually edit it.
>>>
>>> Let me rephrase it:
>>>
>>> « For her birthday, I bought my girlfriend the nice printer she's 
>>> been
>>>   wanting.  The network named it "Printer7839cf31".  Since I love my
>>>   girlfriend, I renamed it to "Mathilda's printer".  Now she can no 
>>> longer
>>>   print. »
>>>
>>>> It would be good if you could come up with a real example. This 
>>>> isn't
>>>> going to happen in practice,
>>>
>>> (Giggle.)
>>
>> We'll see. As it says in every good shop: the customer is always 
>> right.
>>
> Apple doesn’t think so and it may at least partially account for the 
> fact that their products successfully auto-configure way more frequently 
> than those of the competition.

I'm not sure that's as true as it used to be; my recent experiences with
attaching off-the-shelf printers to another o/s have been positive. However,
that's with very simple network topology.

> If there’s a lesson to be learned from this example it’s that either 
> you don’t allow automatically-named things to change their names, or 
> if you provide a user-friendly feature to change the name it “just 
> works” and doesn’t break the associated function. I guess this means 
> that if you rely on DNS to discover and use names, then you provide an 
> update API and not allow “write-behind” to config files (if they 
> exist in the first place).

I agree. Without the ability for users to attach names of their choice
(in scripts of their choice) to devices, there will be millions of
unhappy users.

> Now, if the name-changing auto-configuration functions are broken, then 
> either there has to be a way to diagnose it (maybe only by the people 
> who sold you the printer) and a way to revert to the prior 
> configuration. That diagnostic function does in my view not have to be 
> something easily done by the home user.

Are you sure? The people who sell you printers today operate on very
tight profit margins. In practice, I don't think expert diagnosis is
a realistic expectation.

Regards
Brian

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

Re: [homenet] Introduction to draft-ietf-homenet-simple-naming

[Brian E Carpenter]

On 31/05/2018 08:53, Juliusz Chroboczek wrote:
>> Well, let me invent something. I throw together my network and it
>> names the printers as printer1 and printer2. Being a stickler,
>> I decide to rename them as Printer 1 and Printer 2. I mess around
>> and find a config file somewhere and manually edit it.
> 
> Let me rephrase it:
> 
> « For her birthday, I bought my girlfriend the nice printer she's been
>   wanting.  The network named it "Printer7839cf31".  Since I love my
>   girlfriend, I renamed it to "Mathilda's printer".  Now she can no longer
>   print. »
> 
>> It would be good if you could come up with a real example. This isn't
>> going to happen in practice,
> 
> (Giggle.)

We'll see. As it says in every good shop: the customer is always right.

Brian

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

Re: [homenet] Introduction to draft-ietf-homenet-simple-naming

[Brian E Carpenter]

Well, let me invent something. I throw together my network and it names
the printers as printer1 and printer2. Being a stickler, I decide to
rename them as Printer 1 and Printer 2. I mess around and find a config file
somewhere and manually edit it. My printers no longer work.

All I'm saying is that the design needs to assume that such things will
happen. In the real world, this can't be out of scope.

   Brian

On 31/05/2018 01:17, Michael Richardson wrote:
> 
> Brian E Carpenter  wrote:
> >>>> 1.  Introduction
> >>>> 
> >>>> This document is a homenet architecture document.  The term 'homenet'
> >>>> refers to a set of technologies that allow home network users to have
> >>>> a local-area network (LAN) with more than one physical link and,
> >>>> optionally, more than one internet service provider.  Home network
> >>>> users are assumed not to be knowledgable in network operations, so
> >>>> homenets automatically configure themselves, providing connectivity
> >>>> and service discovery within the home with no operator intervention.
> >>> 
> >>> I would just say, "Homenets are intended for use with minimal or no
> >>> administration, so homenets automatically configure …."  Then we don't
> >>> need to have a boring discussion about what capabilities the user has.
> >>> 
> >> 
> >> I agree. I also believe that not expecting intervention helps in 
> keeping
> >> description deterministic and simple. I like your text.
> 
> > Out of, say, one million homenets, how many do you think *will*
> > experience human intervention (either helpful, harmful, or
> > malicious)? I'm guessing several thousand at least. I really think
> > that not expecting intervention is a basic error.
> 
> I think you are using the wrong metric to count :-)
> Every single homenet will experience human intervention: a human will plug it
> together...
> 
> The question you want to ask is how many times will a human be required to
> configure something which is a normal, every-day activity.  Our goal is zero,
> but 0.1% errors on 1,000,000 is 1,000, which is inline with your number
> above.  0.1% is only "three" nines.
> 
> Then how often will the network need to be interogated for harmful or
> malicious activity. At this point, we are not proposing any mechanisms to
> deal with attacks, or collect information about current attacks, so let's
> make that out of scope for now.
> 
> It's that 0.1% situation that we need some kind of accessible audit
> information available.
> 

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

Re: [homenet] Introduction to draft-ietf-homenet-simple-naming

[Brian E Carpenter]

On 30/05/2018 06:13, Daniel Migault wrote:
...
>>> 1.  Introduction
>>>
>>>This document is a homenet architecture document.  The term 'homenet'
>>>refers to a set of technologies that allow home network users to have
>>>a local-area network (LAN) with more than one physical link and,
>>>optionally, more than one internet service provider.  Home network
>>>users are assumed not to be knowledgable in network operations, so
>>>homenets automatically configure themselves, providing connectivity
>>>and service discovery within the home with no operator intervention.
>>
>> I would just say, "Homenets are intended for use with minimal or no
>> administration, so homenets automatically configure …."  Then we don't
>> need to have a boring discussion about what capabilities the user has.
>>
> 
> I agree. I also believe that not expecting intervention helps in keeping
> description deterministic and simple. I like your text.

Out of, say, one million homenets, how many do you think *will*
experience human intervention (either helpful, harmful, or
malicious)? I'm guessing several thousand at least. I really think
that not expecting intervention is a basic error.

   Brian

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

Re: [homenet] Introduction to draft-ietf-homenet-simple-naming

[Brian E Carpenter]

On 26/05/2018 11:02, Ted Lemon wrote:
> On May 25, 2018, at 1:49 PM, Brian E Carpenter <brian.e.carpen...@gmail.com> 
> wrote:
>> So, the naming system may end up being fully automatic, well or badly
>> managed by a human, or managed autonomically.
> 
> The simple naming architecture is fully automatic, but doesn't do as much as 
> we might want.   I think that the advanced architecture can also be 
> automated, but that's terra incognita.   We are not interested in the use 
> case where naming is managed by the human.   It may be possible for the human 
> to intervene, but it has to work if they don't, and that's the nut we are 
> trying to crack.

Understood. However, many of us exposed to certain operating systems deeply 
hate it when the system thinks it knows what we want better than we do. What 
I'm suggesting is that dealing with unexpected and/or faulty human intervention 
is also necessary. So IMHO human override needs to be thought about, both as a 
risk and as a feature.

   Brian

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

Re: [homenet] Introduction to draft-ietf-homenet-simple-naming

[Brian E Carpenter]

On 26/05/2018 08:06, Michael Richardson wrote:
> 
> Ted Lemon  wrote:
> >> I hate to ask this, but it seems like we ought to have a definition 
> for a
> >> managed network... :-(
> >> I think that the section 2.1 provides contrasts, but maybe we should 
> instead
> >> say what aspects of the Managed LAN we care about.
> 
> > Good point.  The "including the ability to publish services on the
> > Internet" seems like a reasonable first attempt at specifying that, but
> > I agree that it's insufficient.   Do you have a theory to offer?   What
> > I think I meant by this was:
> 
> A managed network is one that has a (human) manager, or operator.
> The operator has authority over the network, and the authority to publish 
> names
> in a forward DNS tree, and reverse names in the reverse tree.
> The operator has the authority to sign the respective trees with DNSSEC,
> and acquire TLS certificates for hosts/servers within the network.

This prompts a few thoughts:

(1) There's a strong resemblance between a homenet and a small office
network, in which there's quite likely to be a human who is supposedly
in charge of the network as a minor part of their job. That may well be
a human who has the authority but not the skills. So there's possibly
a category of "badly managed network" to consider.

(2) I note the "(human)". Actually some of the concepts of autonomics
and intent-based networking may spill over from enterprise networks
into SOHO, at some point in the future.

So, the naming system may end up being fully automatic, well or badly
managed by a human, or managed autonomically.

 Brian

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

Re: [homenet] [Anima] prefix assignment

[Brian E Carpenter]

On 31/03/2017 03:50, Ted Lemon wrote:
> On Mar 30, 2017, at 9:45 AM, Michael Richardson  wrote:
>> It would hand out space via HNCP, and if it ran out of space, get more.
> 
> This can also be done with DHCP.

Indeed. I'm not trying to force the Anima approach, just pointing out that
it will be available in contexts where more than a simple PD operation might
be appropriate.

Brian

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

Re: [homenet] prefix assignment

[Brian E Carpenter]

On 30/03/2017 10:38, Michael Richardson wrote:
> 
> Brian E Carpenter <brian.e.carpen...@gmail.com> wrote:
> >> I just don't see the point of the ASA here.
> 
> > There's already a thing called an HNCP agent. Why couldn't
> > it be enhanced to negotiate with an upstream ASA for resources?
> 
> Because it's already done. It's called DHCPv6.
> It already has extensive running code :-)
> It's not even that complex.

All true. But it isn't designed for negotiation as far as I know,
just a request/response.
 
> I would love to request address space via ASA from the DHCPv6 server.
> That would all happen within the ISP's ACP though.

Agreed, that is a little higher up the food chain. Maybe that is as close
to the user as an ASA will get. I don't really care; I just wanted to
explore the way we might fit our various tools together.

> Right now (on DSL lines), the address space mostly comes via radius.
> Which is to say that the problem has been centralized by MBS builders into
> being someone else's problem. Advertising the address space is often done by
> OSPFv3, but there are additional things that would be easier for the DHCPv6
> server to do, such as the DNS delegations that homenet is working on
> finishing.

Yes, indeed, and then we could discuss how the radius server gets new
address space when it runs out.
 
> I think that CASM could very nicely define/extend the prefix ASA to deal with
> DNS reverse names, and as the RIRs (George) said, better link the delegated
> prefix to clear ownership records.

Yes, by defining a full set of relevant objectives.

Brian

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

Re: [homenet] [Anima] prefix assignment

[Brian E Carpenter]

On 30/03/2017 11:14, Mark Townsley (townsley) wrote:
> 
>> On Mar 29, 2017, at 10:04 AM, Michael Richardson  
>> wrote:
>>
>>
>> This discussion started in a private thread, so I'll try to bring people
>> up-to-date by repeating and moving around text.
>>
>> The ANIMA GRASP reference problem Autonomic Service Agent (ASA), is
>> to do distributed prefix allocation.  This is very much in the space of
>> *coordinated* address management.
>>
>> (My take, BTW, is that CASM should be considered the first spin-off WG
>> From ANIMA...)
>>
>> Mark and Brian discussed how HNCP does prefix distribution within Homenet.
> 
> I was really pointing out that RFC 7695 could be used independent of HNCP. 
> 
> HNCP is just one protocol that uses the RFC 7695 distributed prefix 
> assignment algorithm (which actually began as extensions to OSPF before HNCP 
> even existed).

True. And I don't see any reason why a CASM system including autonomic service
agents shouldn't be used to supply prefixes for use by an RFC7695 
implementation.
So the various tools can fit together.

Brian
> 
> - Mark
> 
>>
>> Brian then suggests:
>>
>>  brian> But if the CE includes a little autonomic service agent (ASA) which
>>  brian> is in the ISP's security domain (not the SOHO domain), it can act for
>>  brian> HNCP to solicit address space from the ISP. That's the southern side
>>  brian> of the CASM model and the northern side of HNCP.
>>
>> I asked a simple question: don't we have DHCPv6 for this?
>>
>> I also then asked:
>>
>>> a) the CPE device is now part of the ISP's ACP.
>>> That's okay if the CPE device is owned by the ISP and/or the CPE device
>>> includes some kind of trusted computation environment.
>>> {But a CPE owned by the ISP, might not be trusted by the home owner,
>>> so another router in between would be needed,
>>
>> Brian answered:
>>> Really? Why not?
>>
>> I don't think that the ISP can trust to have code controlled by end users
>> running in their ACP domain.
>>
>> I also think that many end-users will be quite reasonably upset that their
>> ISPs can snoop on their internal traffic.  This may in fact violate many
>> work-at-home agreements; which is often the case of why you see multiple
>> routers/firewalls in documents like
>> https://datatracker.ietf.org/doc/html/draft-baker-fun-multi-router.
>>
>> (Fred had more interesting diagrams in presentations, which I could dig up)
>>
 b) DHCPv6 PD is already the protocol that solves prefix allocation across
 trust boundaries.
>>
>>> Indeed. That's why we have "PD supported"  as a Boolean property of the
>>> PrefixManager objective. There's no intention to undermine PD.
>>
>> Why do I need to run a protocol in order to find if I can run a protocol,
>> when DHCP has the same mechanism already.  And use of DHCPv6 itself is well
>> defined in cable and DSL connections already.
>>
 I would think that the ISP's DSLAM/BMS/CMTS would have an ASA that deals 
 with
 prefixes.  It would speak DHCPv6-PD to the south, and GRASP/ASA to the 
 north.
>>
>>> Yes, the DSLAM is definitely a good place to put one.
>>
>>
 North of the ISP's device would be the ISP's (distributed) IPAM.
 GRASP/ASA-Prefix would be the protocol between.
>>
>>> Anyway, my point is that these approaches (ANIMA, HNCP and PD) are
>>> complementary not competitors.
>>
>> I don't see you saying that.
>>
>> I see ou trying to extend two internal mechanisms (ANIMA in the ISP, and HNCP
>> in the home) such that they interact directly, rather than using PD.  You
>> say this right here:
>>
>>  brian> But if the CE includes a little autonomic service agent (ASA) which
>>
>>
>> --
>> Michael Richardson , Sandelman Software Works
>> -= IPv6 IoT consulting =-
>>
>>
>>
>> ___
>> homenet mailing list
>> homenet@ietf.org
>> https://www.ietf.org/mailman/listinfo/homenet
> 
> ___
> Anima mailing list
> an...@ietf.org
> https://www.ietf.org/mailman/listinfo/anima
> 

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

Re: [homenet] prefix assignment

[Brian E Carpenter]

On 30/03/2017 10:04, Juliusz Chroboczek wrote:
>> There's already a thing called an HNCP agent. Why couldn't
>> it be enhanced to negotiate with an upstream ASA for resources?
> 
> Could you please clarify what you mean by "negotiate"?  Current HNCP
> implementations are provided with a bunch of External Prefixes, which they
> then carve into /64, one per prefix.  Are you envisioning a scenario where
> the HNCP implementation actually performs active negotiation on its
> external interfaces?

Yes. But if it's a useless use case, that's fine. I was motivated to
point out that there *really* is no conflict between the homenet work
and Anima, and that they could be complementary if we want.

   Brian

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

Re: [homenet] prefix assignment

[Brian E Carpenter]

On 30/03/2017 09:16, Michael Richardson wrote:
> 
> Brian E Carpenter <brian.e.carpen...@gmail.com> wrote:
> > Where you want to plug in an ASA (autonomic service agent) is anywhere
> > you want plug in some intelligence to govern an automatic process.
> > Intelligence, for example, to figure out what to do if the user side
> > asks for a /48 and the ISP offers a /60. So the ASA might negotiate
> > a compromise at /56 and then PD does its thing. But we didn't want
> > to exclude a scenario where PD isn't available, hence a flag is
> > included.
> 
> To put this is pseudo-(monty)pythonesq:
> 
> Customer: Hi, I'd like to buy a parrot.
> Store: Would you like a Blue Parrot or a Red Parrot?
> Customer: I'd like a Blue Parrot.
> Store: I'm sorry, but we don't sell Parrots.

No, it's not really Pythonesque but negotiation is allowed to fail.
 
> I just don't see the point of the ASA here.

There's already a thing called an HNCP agent. Why couldn't
it be enhanced to negotiate with an upstream ASA for resources?

> If DHCPv6-PD isn't available, then it's not a compliant ISP connection
> (RFC7204) and it's outside of the scope of homenet to begin with.

No disagreement; the idea was simply to ensure that the GRASP objective
can communicate that PD is or isn't available. If PD is required in
a particular scenario then that parameter will always be set True.
 
> > About the domain boundary:
> 
> >> I don't think that the ISP can trust to have code controlled by end 
> users
> >> running in their ACP domain.
> 
> > Right. But in ISP-provided CEs this could presumably be fixed, because
> > that code would be locked down. In a store-bought CE, isn't this exactly
> > where BRSKI will help us? There is certainly an issue for home-made CE
> > images, but they will be a tiny minority of users.
> 
> No, BRSKI doesn't help the ISP feel safe that the code I am running
> on my store-bought CE won't attempt to mess with their network.

Yes, I see that. (Unless of course we get into much more complex validation
and authorization stuff, which seems unlikely to fly.)

  Brian

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

Re: [homenet] prefix assignment

[Brian E Carpenter]

OK, I'll front-post.

Where you want to plug in an ASA (autonomic service agent) is anywhere
you want plug in some intelligence to govern an automatic process.
Intelligence, for example, to figure out what to do if the user side
asks for a /48 and the ISP offers a /60. So the ASA might negotiate
a compromise at /56 and then PD does its thing. But we didn't want
to exclude a scenario where PD isn't available, hence a flag is
included.

About the domain boundary:

> I don't think that the ISP can trust to have code controlled by end users
> running in their ACP domain.

Right. But in ISP-provided CEs this could presumably be fixed, because
that code would be locked down. In a store-bought CE, isn't this exactly
where BRSKI will help us? There is certainly an issue for home-made CE
images, but they will be a tiny minority of users.

Brian


On 30/03/2017 04:04, Michael Richardson wrote:
> 
> This discussion started in a private thread, so I'll try to bring people
> up-to-date by repeating and moving around text.
> 
> The ANIMA GRASP reference problem Autonomic Service Agent (ASA), is
> to do distributed prefix allocation.  This is very much in the space of
> *coordinated* address management.
> 
> (My take, BTW, is that CASM should be considered the first spin-off WG
> From ANIMA...)
> 
> Mark and Brian discussed how HNCP does prefix distribution within Homenet.
> 
> Brian then suggests:
> 
>   brian> But if the CE includes a little autonomic service agent (ASA) which
>   brian> is in the ISP's security domain (not the SOHO domain), it can act for
>   brian> HNCP to solicit address space from the ISP. That's the southern side
>   brian> of the CASM model and the northern side of HNCP.
> 
> I asked a simple question: don't we have DHCPv6 for this?
> 
> I also then asked:
> 
> > a) the CPE device is now part of the ISP's ACP.
> > That's okay if the CPE device is owned by the ISP and/or the CPE device
> > includes some kind of trusted computation environment.
> > {But a CPE owned by the ISP, might not be trusted by the home owner,
> > so another router in between would be needed,
> 
> Brian answered:
> > Really? Why not?
> 
> I don't think that the ISP can trust to have code controlled by end users
> running in their ACP domain.
> 
> I also think that many end-users will be quite reasonably upset that their
> ISPs can snoop on their internal traffic.  This may in fact violate many
> work-at-home agreements; which is often the case of why you see multiple
> routers/firewalls in documents like
>  https://datatracker.ietf.org/doc/html/draft-baker-fun-multi-router.
> 
> (Fred had more interesting diagrams in presentations, which I could dig up)
> 
> >> b) DHCPv6 PD is already the protocol that solves prefix allocation 
> across
> >> trust boundaries.
> 
> > Indeed. That's why we have "PD supported"  as a Boolean property of the
> > PrefixManager objective. There's no intention to undermine PD.
> 
> Why do I need to run a protocol in order to find if I can run a protocol,
> when DHCP has the same mechanism already.  And use of DHCPv6 itself is well
> defined in cable and DSL connections already.
> 
> >> I would think that the ISP's DSLAM/BMS/CMTS would have an ASA that 
> deals with
> >> prefixes.  It would speak DHCPv6-PD to the south, and GRASP/ASA to the 
> north.
> 
> > Yes, the DSLAM is definitely a good place to put one.
> 
> 
> >> North of the ISP's device would be the ISP's (distributed) IPAM.
> >> GRASP/ASA-Prefix would be the protocol between.
> 
> > Anyway, my point is that these approaches (ANIMA, HNCP and PD) are
> > complementary not competitors.
> 
> I don't see you saying that.
> 
> I see ou trying to extend two internal mechanisms (ANIMA in the ISP, and HNCP
> in the home) such that they interact directly, rather than using PD.  You
> say this right here:
> 
>   brian> But if the CE includes a little autonomic service agent (ASA) which
> 
> 
> --
> Michael Richardson , Sandelman Software Works
>  -= IPv6 IoT consulting =-
> 
> 
> 

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

Re: [homenet] write up of time without clocks

[Brian E Carpenter]

Barbara,

On 04/11/2016 04:00, STARK, BARBARA H wrote:
>>> I could be wrong, but I believe that Dyn was DDoSed by the Mirai
>>> botnet, which propagates by exploiting devices configured with default
>> credentials.
>>> This has nothing to do with outdated firmwares.
>>
>> The problem is that you cannot realistically update those firmwares.
> 
> Many companies provide devices that do automated updates. It's totally 
> realistic to update firmwares.

Not always. My CE can't be updated any more, I think because its flash memory 
is too small
for recent versions. And I had the same experience a few years ago with a 
previous CE. Not to
mention that most vendors simply stop supporting old hardware after a few 
years. Also
as Juliusz pointed out, if the device was shipped with user admin, password 
admin and the
user (being a normal citizen) doesn't change it, any amount of new vendor 
firmware won't
fix it.

Yes, I agree it's possible to do better, but what's the incentive for a 
bottom-feeding vendor
of cheap devices to bother?

Regards
Brian

> There exist various methods, tools and best practices. The problem is that 
> some manufacturers don't bother to make their
devices upgradable. By not having to maintain the firmware of shipped devices, 
the devices can be sold very inexpensively. So
price-conscious consumers will  buy them, instead of the more expensive, 
well-maintained devices.
> 
>> It is trivial to compile a new firmware for those devices that doesn't 
>> request
>> upnp to open ports to telnet or ssh. But is is impossible to deploy such an
>> update.
> 
> I can't speak for others, but DIRECTV set-top-boxes all do auto update, as do 
> Digital Life IoT devices, and U-verse residential gateways. I think iControl 
> IoT devices do, too. So, no, it's not impossible. It's just cheaper and 
> requires less skill and effort to create devices that can't be updated. The 
> exploited vulnerabilities (in the Dyn attack) have been known for years, and 
> fixes have been available for years. Even after they were known, new units 
> were still shipping with the vulnerability. Secure methods for updating 
> devices and best practices for using these methods have existed for years. If 
> the device manufacturer had built in a mechanism to allow for secure, 
> automated updates (and not hard-coded a default password for access to all 
> devices that couldn't even be changed by firmware update), and had made 
> updates available in a timely manner, there wouldn't have been vast numbers 
> of devices to exploit. 
> 
>> For consumer electronics, we cannot rely on consumers to actually download
>> and install new firmware. So part of the solution to securing those devices
>> has to be that (out of the box) they will update automatically.
> 
> +1
>  
>> For the same reason, having lots of devices on the internet that have been
>> abandoned by the vendor is also a huge security risk. So ideally those 
>> devices
>> should shutdown automatically.
> 
> Which means the vendor would still be responsible for building in a remote 
> "kill switch". Ideally, manufacturers would be required to warn consumers 
> prior to purchase that the device will be bricked (or maybe just have all IP 
> connectivity disabled) if it is ever discovered to have an easily exploitable 
> vulnerability.
>  
>> Note that PCs, browsers, etc. are now somewhat secure because they
>> update automatically. We need to do the same with all other devices
>> connected to the internet.
> 
> +1
> 
> Barbara
> 
> ___
> 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] write up of time without clocks

[Brian E Carpenter]

On 02/11/2016 23:29, Philip Homburg wrote:
>>> So the device should have the vendor's long term TLS certicate. With possibl
>> y
>>> an option for the user to disable this kind of security if the device is
>>> not actually connected to the internet.
>>
>> No, during disaster recovery the last thing you need is for ordinary people
>> to be faced with strange security alerts that they've never seen before.
>> (It's rather like advising people to go into the BIOS to change an option
>> while the fire alarm is ringing.)
>>
>> Things need to just work during disaster recovery.
> 
> Maybe I live in an unusual part of the world. But this seems very far fetched
> to me for two different reasons:
> 
> - I rate the risk of ddos attack like against Dyn way higher than a large
>   physical disaster. Though I have to admit that there are parts of the
>   world where the risk of disaster is a lot larger than here. Of course,
>   building code also very from country to country taking into account
>   disasters that may take place.

It's not an easy trade-off, agreed.

> - The bigger issue is that I can easily imagine partial internet access,
>   but that is mostly unrelated to physical disasters. I'm really curious
>   how you think a disaster leaves the internet broken enough that CPEs
>   can't phone home, but working well enough that people in the middle of
>   can communicate with each other.

If you live (as I do) on a large island in an earthquake prone region, a
disaster that would cut all international Internet links for weeks is far
from impossible, and the vendor servers are all overseas.

> That said, if you think that there is a strong need for CPEs to continue to
> work in a badly damaged internet, then it makes sense to make that an official
> requirement. If requires specifying what this badly damaged internet really
> looks like and how to test if devices can cope.
> 
> Otherwise, CPE vendors may just silently implement what I suggest and we will
> only find out during a disaster where things don't work.

The risk I see is that if a message comes up that says "Cannot contact vendor
server: override security check?" the user will always click "yes". So in fact
this check will be a no-op and also become an attack target in itself.

I have no pixie dust to fix this.

Brian

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

Re: [homenet] write up of time without clocks

[Brian E Carpenter]

On 02/11/2016 03:52, Philip Homburg wrote:
...
> Which brings me to the following: given that all code has security issues,
> maybe devices should check for updates and just shutdown if they can't
> verify that they are running the latest firmware?

That sounds absolutely dreadful for disaster recovery scenarios where
the Internet is badly broken (after a hurricane, earthquake, etc.)
and people need to restart essential systems (or they need to restart
themselves).

> So the device should have the vendor's long term TLS certicate. With possibly
> an option for the user to disable this kind of security if the device is
> not actually connected to the internet.

No, during disaster recovery the last thing you need is for ordinary people
to be faced with strange security alerts that they've never seen before.
(It's rather like advising people to go into the BIOS to change an option
while the fire alarm is ringing.)

Things need to just work during disaster recovery.

Brian

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

Re: [homenet] Why configuration and routing are separate

[Brian E Carpenter]

On 23/07/2016 11:28, Juliusz Chroboczek wrote:
> Speaking with people at this week's IETF meeting, I've realised that some
> are confused about why configuration and routing are implemented by
> different protocols in Homenet.  Contrary to what might seem, this is not
> some sort of weird political compromise, but a conscious technical
> decision.

...

> Please let me know if you're still unconvinced.  I love arguing.

You are 100% correct. They should be separately pluggable, in fact,
in case either of the current choices proves to be a mistake later on.

(Some people may recall that I used homenet as a use case in the UCAN
BOF that preceded the Anima working group. I wish I had articulated
it as clearly as Juliusz has done in the text deleted above. It will
be an interesting exercise, once Anima has done its work, to check that
it would in fact work for a homenet, although its style would be very
different from HNCP.)

   Brian

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

Re: [homenet] Linux 6724 rule 5.5 (Re: draft-bowbakova-rtgwg-enterprise-pa-multihoming-00)

[Brian E Carpenter]

On 21/07/2016 02:34, David Lamparter wrote:
> On Thu, Jul 21, 2016 at 01:22:15AM +1200, Brian E Carpenter wrote:
>> On 21/07/2016 01:13, Lorenzo Colitti wrote:
>>> On Wed, Jul 20, 2016 at 2:54 PM, David Lamparter <equi...@diac24.net> wrote:
>>>
>>>> - it's a bit unclear how an address/prefix's "source" next-hop is kept
>>>>   in association.  The simplistic approach of adding a "PA source ipv6
>>>>   address" for each of a host's configured addresses falls flat when
>>>>   more than 1 router advertises the same prefix, so I implemented it as
>>>>   a list -- however, my hack never removes entries off that.  It should
>>>>   possibly have a copy of the PA's valid time?
>>>>
>>>
>>> The way I thought of doing this would be to alternatively/additionally keep
>>> a pointer from the default router that announced a given prefix (which does
>>> have the link-local address of the router) to each address that was
>>> configured from that prefix. That way, when an address goes away you can
>>> scan the FIB and find another router to associate with that prefix.
>>>
>>> As for lifetimes expiring, you would need to have somewhere to keep dummy
>>> zero-lifetime default routes. It might be possible to do this in the FIB
>>> itself by adding a special entry that doesn't ever match anything, or has
>>> an infinite metric, or a different type...
>>
>> Please tell us ASAP if there is anything we should add to
>> https://tools.ietf.org/html/draft-ietf-6man-multi-homed-host-03#section-3.2
>> or thereabouts.
> 
> I do see some trouble in use-cases where more than one actual router
> (actual = not counting extra link-local addresses on the same router) is
> present on a link, advertising the same prefix to hosts.  (This is
> reasonably likely in homenet scenarios, maybe less in enterprise.)
> 
> If the host only tracks a maximum of one RA source LL for a
> prefix/address, but the router with that LL happens to not be the one
> actually used (e.g. preference, router gone, more specific route from
> RIO, whatever else) then the functionality is lost.  It's particularly
> bad if the one RA source LL is the one prefix was first seen from (and
> then, worst-case, never updated).
> 
> (The neccessary precondition / assumption being broken there is that the
> test "was prefix X announced by router Y" doesn't report false
> negatives.  I haven't applied brain to false positives yet.)

Is this any worse than if the single default router in a traditional host
goes away, which will break all off-link packets until something happens?

I'm not saying it isn't a problem, but it doesn't sound like it's a new
problem that applies only in the multihomed case.

Brian

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

Re: [homenet] Linux 6724 rule 5.5 (Re: draft-bowbakova-rtgwg-enterprise-pa-multihoming-00)

[Brian E Carpenter]

On 21/07/2016 01:13, Lorenzo Colitti wrote:
> On Wed, Jul 20, 2016 at 2:54 PM, David Lamparter  wrote:
> 
>> - it's a bit unclear how an address/prefix's "source" next-hop is kept
>>   in association.  The simplistic approach of adding a "PA source ipv6
>>   address" for each of a host's configured addresses falls flat when
>>   more than 1 router advertises the same prefix, so I implemented it as
>>   a list -- however, my hack never removes entries off that.  It should
>>   possibly have a copy of the PA's valid time?
>>
> 
> The way I thought of doing this would be to alternatively/additionally keep
> a pointer from the default router that announced a given prefix (which does
> have the link-local address of the router) to each address that was
> configured from that prefix. That way, when an address goes away you can
> scan the FIB and find another router to associate with that prefix.
> 
> As for lifetimes expiring, you would need to have somewhere to keep dummy
> zero-lifetime default routes. It might be possible to do this in the FIB
> itself by adding a special entry that doesn't ever match anything, or has
> an infinite metric, or a different type...

Please tell us ASAP if there is anything we should add to
https://tools.ietf.org/html/draft-ietf-6man-multi-homed-host-03#section-3.2
or thereabouts.

Brian

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

Re: [homenet] [v6ops] Linux 6724 rule 5.5 (Re: draft-bowbakova-rtgwg-enterprise-pa-multihoming-00)

[Brian E Carpenter]

On 21/07/2016 00:54, David Lamparter wrote:
> As mentioned on mic during rtgwg, I think the idea of affecting host
> source address selection through 6724 rule 5.5 is potentially very
> useful and IMHO should be explored.

And please note that draft-ietf-6man-multi-homed-host-07 (in IETF Last Call)
recommends hosts to support this, exactly to assist SADR solutions.

Brian

> Hence, I hacked it up for the Linux (4.5.0) kernel; patches are attached
> to this mail.  I've been able to gleam a little more detail on the idea:
> 
> - it's a bit unclear how an address/prefix's "source" next-hop is kept
>   in association.  The simplistic approach of adding a "PA source ipv6
>   address" for each of a host's configured addresses falls flat when
>   more than 1 router advertises the same prefix, so I implemented it as
>   a list -- however, my hack never removes entries off that.  It should
>   possibly have a copy of the PA's valid time?
> 
>   (Read as: the "Discussion" note in 6724 is right on the mark - the
>   details are not quite specified.)
> 
> - in that avenue, I don't think it's possible to store the information
>   in a route-centric way, because RA lifetimes tend to be shorter.
>   If a router goes away and comes back, it seems to me that the prefix's
>   associated origin/nexthop should still be there.
> 
> - rule 5.5 makes RA preference carry into source address selection.  I
>   think this is described in the draft, I just failed to grasp that from
>   the presentation.  Very useful for getting source selection right in
>   the face of unequal performance uplinks.
> 
> - if you want to manage this in an userspace process on Linux, you can
>   simply update the route's preferred source attribute.
> 
> The attached patchset also has the following caveats that result from me
> just doing a quick hack:
> - there is no debugging/user visibility of the value
> - as mentioned above, tracked source addresses never go away unless the
>   entire address dies.  It caps at 4 sources (so you can't exhaust
>   kernel memory by spoofing...)
> - I should probably pass Linux's "dst" instead of "rt6_info"
> - I didn't check for locking/concurrentness violations
> - there's a const warning which I ignored.
> 
> Either way if anyone wants to tinker with it, here it is.
> No warranties, YMMV.  You touch it, it becomes your responsibility ;)
> 
> Cheers,
> 
> 
> -David
> 
> On Wed, Jul 06, 2016 at 04:33:18PM +, Fred Baker (fred) wrote:
>> At IETF 94, this working group advised the routing ADs and Routing Working 
>> Group that PA multihoming would not work without a source/destination 
>> routing solution. This draft was developed in response. Routing Working 
>> Group requests v6ops review.
>>
>>> Begin forwarded message:
>>>
>>> From: 
>>> Subject: New Version Notification for 
>>> draft-bowbakova-rtgwg-enterprise-pa-multihoming-00.txt
>>> Date: July 5, 2016 at 5:58:25 PM PDT
>>> To: Chris Bowers , Jen Linkova , 
>>> "Fred Baker" , "J. Linkova" 
>>>
>>>
>>> A new version of I-D, draft-bowbakova-rtgwg-enterprise-pa-multihoming-00.txt
>>> has been successfully submitted by Fred Baker and posted to the
>>> IETF repository.
>>>
>>> Name:   draft-bowbakova-rtgwg-enterprise-pa-multihoming
>>> Revision:   00
>>> Title:  Enterprise Multihoming using Provider-Assigned 
>>> Addresses without Network Prefix Translation: Requirements and Solution
>>> Document date:  2016-07-05
>>> Group:  Individual Submission
>>> Pages:  44
>>> URL:
>>> https://www.ietf.org/internet-drafts/draft-bowbakova-rtgwg-enterprise-pa-multihoming-00.txt
>>> Status: 
>>> https://datatracker.ietf.org/doc/draft-bowbakova-rtgwg-enterprise-pa-multihoming/
>>> Htmlized:   
>>> https://tools.ietf.org/html/draft-bowbakova-rtgwg-enterprise-pa-multihoming-00
>>>
>>>
>>> Abstract:
>>>  Connecting an enterprise site to multiple ISPs using provider-
>>>  assigned addresses is difficult without the use of some form of
>>>  Network Address Translation (NAT).  Much has been written on this
>>>  topic over the last 10 to 15 years, but it still remains a problem
>>>  without a clearly defined or widely implemented solution.  Any
>>>  multihoming solution without NAT requires hosts at the site to have
>>>  addresses from each ISP and to select the egress ISP by selecting a
>>>  source address for outgoing packets.  It also requires routers at the
>>>  site to take into account those source addresses when forwarding
>>>  packets out towards the ISPs.
>>>
>>>  This document attempts to define a complete solution to this problem.
>>>  It covers the behavior of routers to forward traffic taking into
>>>  account source address, and it covers the behavior of host to select
>>>  appropriate source addresses.  It also covers any possible role that
>>>  routers might play in providing information to 

Re: [homenet] RFC 7788 and ".home"

[Brian E Carpenter]

On 19/07/2016 04:40, Andrew Sullivan wrote:
> On Tue, Jul 19, 2016 at 03:22:57AM +1200, Brian E Carpenter wrote:
>> I don't get that. There's nothing about that in RFC 6761, which is mainly
>> very boring stuff that could be written up for this case, regardless
>> of the actual domain name. It's our own self-imposed bureaucracy.
> 
> Question 7 asks how registries and registrars should react to this
> name.  Given that the home TLD is in-process in the ICANN delegation
> procedures from the root zone, it is logically possible that at any
> moment ICANN could change its administrative procedures and home would
> get delegated.
> 
> So the answer to question 7 cannot be but ambiguous under these
> circumstances.  To me, that means that the requirements of 6761 can't
> possibly be met by home, and therefore home can't be allocated under
> special use.

Oh, I didn't interpret q7 quite that way. I would have answered
it with virtually the same text as q7 for localhost in RFC6761.
In fact several of the answers for localhost would serve for this case,
I think.

> This is the point that Jari made and that I was going to make at the
> mic: this isn't a mere political problem, but an actual functional one
> under our own procedures.  There is just no way we could allocate home
> under 6761 right now, without a very strong statement from ICANN that
> it would be ok.

I agree, but I see that as a meta-issue rather than an RFC6761 issue.

> I also argue (see my note from yesterday) that generalizing from
> "people seem to be doing somehting like this with this name, because I
> talked to a guy from $vendor and he said so" to "using this as a
> protocol switch in a protocol will not have a problem" seems to me to
> require a pretty big leap.

I agree. A brand new name with no known usage is a safer path.

>> RFC 6761 is one thing, but RFC 2860 is another. Under note (a)
>> to clause 4.3 of that MoU, the IETF can direct IANA to reserve
>> .$WHATEVER$. for technical use.
> 
> I strongly agree -- that part is the very reason why 6761 was even
> possible, in my opinion.
>  
>> Doing so for .home. would be entertaining, of course. Doing so
>> for .homenet. seems plausible.
> 
> I know it can be entertainment to watch those films where someone
> foolishly got into a car that was then swept over Niagara Falls.

As long as it isn't your own car.

   Brian

> 
> A
> 

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

Re: [homenet] RFC 7788 and ".home"

[Brian E Carpenter]

On 19/07/2016 03:40, Mikael Abrahamsson wrote:
> On Tue, 19 Jul 2016, Brian E Carpenter wrote:
> 
>> Doing so for .home. would be entertaining, of course. Doing so for .homenet. 
>> seems plausible.
> 
> It seems to already be used for that, and as said before, ICANN has refused 
> all applications for .home already.
> 
> .home is tainted by ad-hoc use. The ad-hoc use seems to be exactly the same 
> use as RFC7788 uses it for.
> 
> Why not formalise it?

To be blunt, because ICANN and possibly the IETF would get sued for many M$.

   Brian

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

Re: [homenet] Which IP addresses must be avoided?

[Brian E Carpenter]

On 18/05/2016 04:01, Bless, Roland (TM) wrote:
...
> https://tools.ietf.org/html/rfc7136
> is probably also of interest.

In particular, it means you do *not* need specific values for the u/g bits 
these days.

Brian

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

Re: [homenet] Homenet Naming Architecture

[Brian E Carpenter]

On 21/01/2016 18:36, Douglas Otis wrote:
...
> The TLD '.lo' looks somewhat like a ccTLD

AFAIK, two letter TLDs are all implicitly reserved since any of them might
pop up in ISO 3166 in the future. I'm not enough of an ICANNologist to
point to where this is established (to my surprise, it is not established
by RFC 1591).

LO is currently unassigned in ISO 3166, but of course that could change
as a result of some future geopolitical event.

So it would be really foolish of the IETF to consider .lo at all.

Brian

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

Re: [homenet] Kathleen Moriarty's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS)

[Brian E Carpenter]

Ted,

> The bottom line is that I think the reason you have given for not making DTLS 
> MTI is a really bad one.   There is a perfectly good DTLS implementation out 
> there, which is quite easy to use as far as I can tell,

So I am puzzled. If that is the case, it is not the HNCP implementer who has to
write any DTLS code (in my book, the word "implement" in a protocol spec means
"write code"). At most there would need to be a few extra instructions to wrap
a socket in DTLS, and that code would likely be ifdeffed because it would
only be used when needed. Which sounds exactly like a SHOULD to me.
Or maybe "mandatory to be able to switch on." In any case, not part of the
HNCP protocol itself.

Regards
   Brian

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

Re: [homenet] Kathleen Moriarty's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS)

[Brian E Carpenter]

On 19/11/2015 17:14, Ted Lemon wrote:
> Wednesday, Nov 18, 2015 6:49 PM Juliusz Chroboczek wrote:
>> It's not a simple matter of sending a few mailing list messages -- it's
>> a long-term effort that consists of writing portable, open source,
>> lightweight implementations (hnetd, shncpd), of deploying HNCP ourselves
>> (Paris network, Henning's network somewhere in Germany), of getting HNCP
>> implementations into Linux and Unix distributions (OpenWRT by Steven,
>> Debian/Ubuntu soon, I'm not telling), of speaking to people at community
>> meetings (Battlemesh, IETF, CCC, FOSDEM), in short, making HNCP familiar
>> and easily available.
> 
> Sure, that's fair enough.
> 
>> (And as we're trying to communicate our message in a clear and accurate
>> manner, how helpful it is to be able to say that a feature is "mandatory
>> to implement, optional to use, but you're not allowed to #ifdef it away".)
> 
> Just to clarify, mandatory to implement doesn't mean you have to write the 
> code.   It means the functionality has to be present in the deployed 
> implementation so that two communicating partners can be configured to use 
> it.   

Um, where is that defined? Is there a BCP that says that?

I don't think a protocol spec can say that feature X cannot be ifdeffed.
It can say that a protocol must be capable of X and that implementations
must therefore be capable of X. But if you tell implementors that they can't
ifdef unused stuff when building images for highly constrained nodes, I
don't think they will take you seriously.

   Brian


Mandatory to use means that the functionality has to be used at all times.
> 
> 
> --
> Sent from Whiteout Mail - https://whiteout.io
> 
> My PGP key: https://keys.whiteout.io/mel...@fugue.com
> 
> 
> 
> ___
> 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] Reachability of distributed prefixes

[Brian E Carpenter]

On 01/09/2015 01:24, Gert Doering wrote:
> Hi,
> 
> On Sun, Aug 30, 2015 at 10:03:47PM -0700, joel jaeggli wrote:
 And that's a well-known issue that the IETF needs to finally tackle:
 source-address failover. 
>>
>> So long as you don't invoke the prospect of either extremely expnesive
>> overlay networks, or globably route scalability go right ahead those are
>> both in play already.
>>
>> Hosts in in absence of state as turns out are rather good at
>> instantaneous renumbering. e.g. as they roam  between networks it
>> remains a mystery to me that networks  containy hosts are less able to
>> cope. I may be in fact that that they are not less able to cope.
> 
> No, that wasn't what I was talking about.  Not "I get a new source address
> and need to cope it", but "I have two source addresses with global scope,
> tried one according to source-selection rules, it did not work, so I 
> should maybe try the other one now?"

Yes, you're correct that shim6 doesn't do that, and has other deployability
issues that I noted. But unless we want every application and/or transport
protocol to contain its own variant of happy eyeballs, this functionality
(suck-it-and-see-until-it-works) would need to be inserted as a shim in the
socket layer or somewhere around there.

I'm not convinced there's a protocol involved, though. It's more a matter
of "history", in the sense used in draft-baker-6man-multi-homed-host.

   Brian

> 
> No network dynamics of any kind involved, just "a normal homenet 
> multi-ISP scenario" (with some breakage "somewhere upstream", not 
> something the host can easily see) - I thought that this would have been 
> obvious from the thread and WG list context.
> 
> The advertised IETF solution for "(SoHo) multihoming" is "multiple global 
> IPv6 addresses", but this does not work yet as well as it could, partly 
> due to this missing piece.
> 
> Gert Doering
> -- NetMaster
> 

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

Re: [homenet] Getting new HNCP TLV types

[Brian E Carpenter]

On 20/08/2015 08:02, Juliusz Chroboczek wrote:
 Why are HNCP codepoints specified as standards action?  It's a 16-bit
 space, wouldn't documentation required be good enough?  Or even FCFS?

With my RFC6709 hat on, I would advocate a fairly strict policy for
extending something that walks and quacks like a routing protocol.
Some sort of review seems advisable. In RFC5226 terms, I'd go for
Expert Review at least.

Brian

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

Re: [homenet] HNCP: avoiding renumbering

[Brian E Carpenter]

On 17/08/2015 11:01, Juliusz Chroboczek wrote:
 which avoids renumbering.
 
 Why do we care? Homenets need to be renumbering-proof anyway, because
 the ISP might change the prefix anytime.
 
 You're right, that deserves clarifying.  We're trying really hard to make
 sure that in no circumstances is running a Homenet router worse than
 running an ordinary NAT/DHCPv6-PD router.  Consider the following trivial
 topology:
 
 ISP  Homenet router  stub link
 
 We'd like to ensure that:
 
   - the NATed IPv4 prefix assigned to the stub link remains stable;
   - if the /56 delegated by the ISP is stable, then the global /64
 assigned to the stub link remains stable;
   - if the Homenet router is announcing a ULA, then the ULA /64 assigned
   - to the stub link remains stable.
 
 In short, we'd like any prefix assignments performed by the Homenet router
 to survive a reboot, even in the absence of either explicit configuration
 or stable storage.

That may be desirable, but must not be depended on. The homenet architecture
is explicit on pp 25-26 that renumbering is an expected event:
https://tools.ietf.org/html/rfc7368#page-26
The addressing, routing and naming architecture has to be ready for
renumbering at any time. Anything else is broken.

Brian

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

Re: [homenet] HNCP: avoiding renumbering

[Brian E Carpenter]

On 17/08/2015 11:01, Juliusz Chroboczek wrote:
 which avoids renumbering.
 
 Why do we care? Homenets need to be renumbering-proof anyway, because
 the ISP might change the prefix anytime.
 
 You're right, that deserves clarifying.  We're trying really hard to make
 sure that in no circumstances is running a Homenet router worse than
 running an ordinary NAT/DHCPv6-PD router.  Consider the following trivial
 topology:
 
 ISP  Homenet router  stub link
 
 We'd like to ensure that:
 
   - the NATed IPv4 prefix assigned to the stub link remains stable;
   - if the /56 delegated by the ISP is stable, then the global /64
 assigned to the stub link remains stable;
   - if the Homenet router is announcing a ULA, then the ULA /64 assigned
   - to the stub link remains stable.
 
 In short, we'd like any prefix assignments performed by the Homenet router
 to survive a reboot, even in the absence of either explicit configuration
 or stable storage.

That may be desirable to limit churn, but must not be depended on. The
architecture is explicit on pp 25-26 that renumbering is an expected event:
https://tools.ietf.org/html/rfc7368#page-25
The addressing, routing and naming architecture has to be ready for
renumbering at any time. Anything else is broken.

Brian

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

Re: [homenet] I-D Action: draft-baker-6man-multi-homed-host-00.txt

[Brian E Carpenter]

On 16/08/2015 21:31, Steven Barth wrote:
 Am 10.08.2015 um 19:28 schrieb Fred Baker (fred):
 In any event, I would urge the HNCP design team to consider the cases, and 
 either make an argument that making network routing more complex (BCP 84) 
 has a benefit I'm missing and actually works without the rule, or change 
 HNCP to not have each RA contain every possible prefix.
 
 After scanning the discussions here, is there anything in particular that 
 people feel which we need to add or clarify in HNCP for that matter?
 
 It seems to me that the current behavior, i.e., potentially non-optimal 
 router sending out the PIO
 and then relying on redirection / routing does not really break things. 

I think Pierre was saying in Prague that it does break things in the case
of extra hops on very lossy wireless networks.

 Optimizing the PIO sending might in theory be
 possible but - as pointed out - is probably very hard to accomplish in 
 practice.
 
 In addition, as a personal note from my own reading, I'm not 100% convinced 
 that hosts even following the next-hop
 tracking of 6724 would correctly react to potential handover of a PIO from 
 one router to another since the definition
 is relatively vague.

That is probably true today but hopefully doesn't have to stay true
for the next hundred years.

Brian

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

Re: [homenet] HNCP: avoiding renumbering

[Brian E Carpenter]

n 17/08/2015 01:01, Markus Stenberg wrote:
 
 On 16.8.2015, at 14.40, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr 
 wrote:
 When an HNCP router is restarted, the prefixes it allocated to a link are
 adopted by neighbouring routers; if the router then restarts, it will
 agree to the prefixes advertised by its neighbours, which avoids
 renumbering.

Why do we care? Homenets need to be renumbering-proof anyway, because the ISP
might change the prefix anytime.

(We could contrive to have a stable ULA prefix, of course, but that only
affects in-home communications.)

Brian

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

Re: [homenet] Fwd: I-D Action: draft-baker-6man-multi-homed-host-00.txt

[Brian E Carpenter]

On 15/08/2015 22:58, Juliusz Chroboczek wrote:
 Filename: draft-baker-6man-multi-homed-host-00.txt
 
 I find the structure of this document puzzling.  Shouldn't Section 4 be
 moved before Section 3, so that current sections 2 and 4 become 2.1 and 2.2?

Possibly. We do want to be sure that the routing community takes note of
the current Section 4, which is why it is separate despite being very short.

Thanks
Brian

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

Re: [homenet] I-D Action: draft-baker-6man-multi-homed-host-00.txt

[Brian E Carpenter]

On 13/08/2015 17:23, Mikael Abrahamsson wrote:
 On Thu, 13 Aug 2015, Brian E Carpenter wrote:
 
 I still don't understand what a host with an IA_NA or IA_PD that isn't 
 covered by an on-link PIO should do with a packet sourced
 from those IA_NA/IA_PD addresses. Yes, I do believe this to be a very valid 
 case.

 I think we're saying: there needs to be a PIO if it matters which first-hop
 router such a host picks. If it doesn't matter (i.e. there is a complete 
 local
 routing cloud with SADR, or there is no BCP 38 filter) then the host can
 use any first-hop router it wants.
 
 Can it be an L=0 PIO?

I would think so. L=0 conveys no information, after all,
according to RFC 4861: When not set the advertisement makes
no statement about on-link or off-link properties of the prefix.

So I think the -01 draft is wrong, since it says on-link.

Brian

 
 How the router knows to send that PIO is not a problem for the host,
 therefore not in scope in this draft. (But there's no doubt in my mind that
 life is simpler if you don't use DHCPv6.)
 
 Of course, but the use-case of having IA_NA that isn't covered by an on-link 
 PIO Is useful in some scenarios (where for instance
 you have configured the L2 network so that devices can't talk directly to 
 each other, and you want to make the L3 configuration
 reflect this so you don't have to do magic tricks like local-proxy-arp 
 (whatever that would be called in IPv6)).
 

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

Re: [homenet] I-D Action: draft-baker-6man-multi-homed-host-00.txt

[Brian E Carpenter]

On 14/08/2015 14:46, Fred Baker (fred) wrote:
 
 On Aug 13, 2015, at 7:37 PM, Brian E Carpenter brian.e.carpen...@gmail.com 
 wrote:

 So I think the -01 draft is wrong, since it says on-link.
 
 What is says is
 
A host receives prefixes in a Router Advertisement [RFC4861], which
goes on to identify whether they are usable by SLAAC [RFC4862]
[RFC4941] [RFC7217].  When no prefixes are usable for SLAAC, the
Router Advertisement would normally signal the availability of DHCPv6
[RFC3315] and the host would use it to configure its addresses.  In
the latter case it will be generally the case that the configured
addresses match one of the prefixes advertised in a Router
Advertisement that are supposed to be on-link in that subnet.
 
Since the host derives fundamental default routing information from
the Route Advertisement, this implies that, in any network with hosts
using multiple prefixes, each prefix SHOULD be advertised via on-link
Prefix Information Options [RFC4861] by one of the attached routers,
even if addresses are being assigned using DHCPv6.  A router that
advertises a prefix indicates that it is able to appropriately route
packets with source addresses within that prefix.
 
 Tell me what to make it say.
 

I think all we have to do is delete 'on-link' in the second paragraph.
(The 'generally' in the first paragraph allows for the exceptional
case that Mikael was concerned about, I think.)

   Brian

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

Re: [homenet] I-D Action: draft-baker-6man-multi-homed-host-00.txt

[Brian E Carpenter]

Below...
On 13/08/2015 06:42, Mikael Abrahamsson wrote:
 On Wed, 12 Aug 2015, Ole Troan wrote:
 
 For DHCPv6 these contraints do not apply anymore. That's what I'm trying to 
 figure out, how do we handle these IA_NAs and
 IA_PDs that are not within an on-link RA being sent for that prefix.

 I take it IA_PD was included above by mistake.
 
 No.
 
 This is definitely not a configuration error, it's perfectly valid to hand 
 out single address using DHCPv6 IA_NA that isn't
 covered by an off-link or on-link prefix.

 true. but I’m not sure what bearing that has with the host rule in question.
 I’m also wondering if you are making a wrong assumption of what an L=0 PIO 
 entails.
 
 I don't know. Am I?
 
 I still don't understand what a host with an IA_NA or IA_PD that isn't 
 covered by an on-link PIO should do with a packet sourced
 from those IA_NA/IA_PD addresses. Yes, I do believe this to be a very valid 
 case.

I think we're saying: there needs to be a PIO if it matters which first-hop
router such a host picks. If it doesn't matter (i.e. there is a complete local
routing cloud with SADR, or there is no BCP 38 filter) then the host can
use any first-hop router it wants.

How the router knows to send that PIO is not a problem for the host,
therefore not in scope in this draft. (But there's no doubt in my mind that
life is simpler if you don't use DHCPv6.)

Brian

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

[homenet] Off topic [was: Layering [was: Despair]]

[Brian E Carpenter]

On 09/08/2015 09:04, Geoff Thompson wrote:

...
 The success of the (reasonably well layered) TCP/IP suite would indicate
 that the market has decided that this is a cost well worth paying.
 
 Precisely my point, except that it is not true.  The datagram service that 
 was provided for with such success by TCP/IP does not provide the same 
 service over all physical layers.  In fact the now predominant physical 
 layers do not provide sufficiently low-jitter, low loss service for all 
 legacy services to work well.

You mean, sufficient compared with 4800 baud modems over spotty analogue
phone lines, which were predominant when those legacy apps, right up
to HTTP/1.0, were invented?

What don't work well are *modern* services invented for broadband, in
the absence of anything accurately described as broadband.

But, yes, I hope the final list of requirements for the homenet routing
protocol includes: works adequately on lossy wireless media with poor
multicast support.

Brian

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

[homenet] New work in other SDOs [was Despair]

[Brian E Carpenter]

On 08/08/2015 02:44, Weil, Jason wrote:
 Are you suggesting that IEEE and IETF send liaison letters to each other
 when they begin crafting new protocols? 

Actually such a mechanism has existed for 15 years or so: the infamous
new-w...@ietf.org list, which I invented. It's a closed list (at this
point I forget why, but I imagine some SDOs have a complex about it)
populated by various liaisons. The theory was for SDOs to notify each
other about possibly overlapping new work in a more simple way than a
formal liaison statement. Because it's closed, I have no idea whether
there's any recent traffic.

 This could possibly be useful
 assuming anyone acted on it. The more likely scenario is for each SDO to
 send an liaison saying ³Hey we just spent x years designing our new
 protocol y, please take a look and see if your protocols both past and
 present will function efficiently over it.²

... with a P.S. apologising for having forgotten to mention it x years
ago on the new-work list. Yes, that's exactly what has happened before
now.

Brian

 
 In my experience there seems to be very little overlap between engineers
 working in the IEEE and those working in the IETF. My company for example
 has exactly zero overlap. IPv6 Multicast over IEEE 802.11 seems to be a
 good example of how more interaction would be immensely useful early on in
 the protocol development process. I¹m not sure there is a fix here, but it
 would definitely be useful for both SDOs to keep in mind each others
 protocols for interoperability purposes instead of just pointing to the
 other to fix their protocols.
 
 Customers
 
 Jason
 
 On 8/7/15, 2:21 AM, Mikael Abrahamsson swm...@swm.pp.se wrote:
 
 On Thu, 6 Aug 2015, Pascal Thubert (pthubert) wrote:

 It is simply unfair from the IETF to use Wi-Fi as if it was Ethernet
 and
 then complain to IEEE that in fact it is not.

 This is an interesting viewpoint. IETF isn't using wifi as if it was
 Ethernet. The customers who buy Wifi products buy it and run IP over it,
 expecting it should work (because that's what the advertising says). IP
 has been designed for wired ethernet (and Wifi carries ethernet frames).
 As far as I can tell, 802.11 never told the IETF that it wouldn't support
 multicast (really).

 I'd say IETF isn't saying IP works great over Wifi (it doesn't really
 make any claims for any L1 or L2). However, I see producers of Wifi
 equipment saying that their products are great for using to connect to
 the
 Internet, which is saying Wifi is great for IP.

 IPv6 over Ethernet makes heavy use of multicast over Ethernet, which
 for
 the lack of a highly scalable Multicast service always ends up
 broadcasted over the whole fabric.

 When Wi-Fi is confused with Ethernet and the whole multi link becomes a
 single layer 2 fabric, we create a crisis that will not be solved by
 imputing the responsibility on the other SDO.

 Which is exactly why I said that both SDOs need to do something. However,
 since IP was first I think that 802.11 should have come to IETF a long
 time ago and said that it couldn't do multicast. Basically, what I
 interpret you're saying is that Wifi in its current form isn't suited to
 carry IP the way IP has been designed, for a long time. That would be
 news
 for a lot of people.

 My suggestion is to finally recognize that Wi-Fi is not Ethernet, in
 particular from the perspective of multicast, and provide the
 appropriate L3 mechanisms for IPv6 over Wi-Fi, for which the backbone
 router discussed above is one candidate solution.

 It's not only IPv6, but it's also IPv4 (since it uses broadcast, but less
 of it).

 But what I hear here is that your opinion is that 802.11 doesn't need to
 change, but the IETF needs to change for IP to work over Wifi. I'd really
 appreciate some kind of official agreement from each SDOs who should do
 what. If the long-term technical solution is that the IETF should change
 L3 to basically avoid broadcast and multicast, then that's fine, as long
 as this is agreed upon by both parties.

 However, I do think that 802.11 needs to point out to its members that if
 they don't implement assured multicast replication, IP doesn't work
 properly. Then they can decide what should be done in the short term,
 because changing IP will take quite a while.

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

 ___
 homenet mailing list
 homenet@ietf.org
 https://www.ietf.org/mailman/listinfo/homenet
 
 
 This E-mail and any of its attachments may contain Time Warner Cable 
 proprietary information, which is privileged, confidential, or subject to 
 copyright belonging to Time Warner Cable. This E-mail is intended solely for 
 the use of the individual or entity to which it is addressed. If you are not 
 the intended recipient of this E-mail, you are hereby notified that any 
 dissemination, distribution, copying, or action taken in relation to the 
 contents of and attachments to this E-mail is 

Re: [homenet] Moving forward.

[Brian E Carpenter]

On 05/08/2015 08:26, farina...@gmail.com wrote:
 
 
 On Aug 4, 2015, at 12:47 PM, David Oran daveo...@orandom.net wrote:

 I think Dino was referring to high-fequency non-human events that can cause 
 links and boxes to flap.
 
 Right. If we had route flaps once a minute, I would consider that not often. 

What about a lousy wireless link that drops, say, one packet in two?

   Brian

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

Re: [homenet] shncpd and Router Advertisements, comments on hncp-06

[Brian E Carpenter]

On 14/07/2015 10:26, Lorenzo Colitti wrote:
 On Jul 13, 2015 12:28, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr
 wrote:
 
   - I'm setting the A flag even for prefix lengths different from /64,
 which is a reasonable thing to do according to my reading of RFC 7421.
 
 What's the point of sending A=1 with a prefix length that's not 64?

Heh heh. That's part of why we wrote RFC7421.

Architecturally, A=1 and prefix length =N is perfectly fine, if and only
if all SLAAC-capable nodes on the link know how to generate an IID
of length 128-N.

In the real world this only works for N=64 today. afaik, there is no way
to negotiate a different value. IMHO it would have to be pre-configured
in every node on the link, but architecturally Juliusz is correct.

 Brian

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

Re: [homenet] Redirect and source-specific routing

[Brian E Carpenter]

On 13/07/2015 02:30, Juliusz Chroboczek wrote:
 I'm wondering if there isn't some interaction between Redirect messages and 
 source-specific routing that we're overlooking. 
 RFC 4861 Section 8.3 says the following:
 
Redirect messages apply to all flows that are being sent to a given
destination.  That is, upon receipt of a Redirect for a Destination
Address, all Destination Cache entries to that address should be
updated to use the specified next-hop, regardless of the contents of
the Flow Label field that appears in the Redirected Header option.
 
 It does not speak of the source address, so I assume that this applies to all 
 sources. 

It definitely should not, since in some topologies that might send packets
directly to a BCP38 filter. I think that's a 6man issue. I might even have to
modify my slides for 6man.

Brian

 Consider the following topology:
 
 A ---+--- B 
  |
  H
 
 If A and B advertise non-overlapping source-specific default routes and H is 
 multiplexing its traffic over source addresses in
 both source prefixes (say, it's using MP-TCP), its Destination Cache entry 
 will flap between A and B.
 
 If I'm right, that argues in favour of an update to RFC 4861.
 
 -- 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] IntDir review: draft-ietf-homenet-dhcp-07

[Brian E Carpenter]

On 13/07/2015 03:05, Steven Barth wrote:
 Hello Ole,

...
 = Add a reference to Merkle trees?
 I'm not certain what would be a good source to quote here, maybe Merkle's
 paper from '87 or the ‘92 patent? At least there doesn't seem to be
 a really appropriate reference.

His PhD thesis seems to be the best formal reference:

www.merkle.com/papers/Thesis1979.pdf
http://dl.acm.org/citation.cfm?id=909000

If you want to actually know what a Merkle tree is:
https://en.wikipedia.org/wiki/Merkle_tree

   Brian

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

Re: [homenet] Objection to late change in draft-ietf-homenet-prefix-assignment

[Brian E Carpenter]

On 09/07/2015 02:10, Steven Barth wrote:
 
 
 Am 07.07.2015 um 23:24 schrieb Brian E Carpenter:
 Your explanation is fine but the phrase and can therefore be used in
 fully autonomic as well as professionally managed networks still makes
 some big assumptions. How about and can therefore be used more
 widely than in unmanaged home networks?
 
 I would disagree here, the statement autonomic or fully autonomic is 
 perfectly
 fitting for the kind of networks this algorithms can be used in. It can 
 certainly
 also be used in professionally managed networks or do you see any reason why 
 it
 cannot?

The current text implies (to me) that it's necessary and sufficient, which is
definitely not the case and was never discussed in the WG anyway. The change
most recently suggested by Pierre is OK for me.

Rgds
   Brian


 
 This said, it does not necessarily mean that it is a perfect fit for all 
 kinds of
 these networks, but nobody did claim that either. It is extensible though so 
 there
 is no way to discard it for these usecases that easily.
 
 
 Cheers,
 
 Steven
 

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

Re: [homenet] Objection to late change in draft-ietf-homenet-prefix-assignment

[Brian E Carpenter]

That seems OK to me. There are some aspects that we need to
discuss over in Anima in due course.

   Brian
On 09/07/2015 01:53, Pierre Pfister wrote:
 Thank you for this proposal.
 
 In the same spirit (but reducing the amount of changes), what about 
 « and can therefore be used in fully autonomic as well as configured networks 
 »  ?
 
 I think « configured » has a smaller scope than « professionally managed 
 network ».
 
 - Pierre
 
 
 Le 7 juil. 2015 à 23:54, Meral Shirazipour meral.shirazip...@ericsson.com 
 a écrit :

 Hi,
  Thanks for including me. Adding back gen-art list to this thread. I am ok 
 with Brian's suggested text. 

 Best,
 Meral

 -Original Message-
 From: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com] 
 Sent: Tuesday, July 07, 2015 2:25 PM
 To: Pierre Pfister
 Cc: IESG; homenet@ietf.org; Meral Shirazipour
 Subject: Re: [homenet] Objection to late change in 
 draft-ietf-homenet-prefix-assignment

 Pierre,

 Thanks for the prompt reply. I am not too worried about the process issue, 
 and I do understand why that whole paragraph was added (I've added Meral in 
 cc).

 Your explanation is fine but the phrase and can therefore be used in fully 
 autonomic as well as professionally managed networks still makes some big 
 assumptions. How about and can therefore be used more widely than in 
 unmanaged home networks?

 I will be in Prague as well and would be happy to discuss whether PA could 
 be useful to Anima.

 I can easily imagine an autonomic service agent (in Anima terminology) using 
 this algorithm (quite independent from whether it uses DNCP).

 Regards
   Brian

 On 08/07/2015 08:38, Pierre Pfister wrote:
 Hello Brian,

 This change was introduced after the Gen-ART review from Meral Shirazipour, 
 I quote:
  I found the draft a bit hard to follow as the incentive was not clear at 
 first. 
  A few sentences in abstract or introduction on 'why' we need this 
 algorithm and what would the 'alternatives' be would be useful. Right now 
 it only says 'what' the algorithm does.

 This whole paragraph was therefore added:
   This document specifies a distributed algorithm for automatic prefix
   assignment.  The algorithm provides a generic alternative to
   centralized (human or software based) approaches for network prefixes
   and addresses assignment.  Although it does not require to be
   configured to operate properly, it supports custom configuration by
   means of variable priority assignments, and can therefore be used in
   fully autonomic as well as professionally managed networks.

 Its purpose is to clarify the goal of the algorithm in a short sentence.

 Digging back into my mails, I realize that the exchange I had about this 
 update with Meral was private.
 My mistake, i thought the mailing list was cc’d to the discussion. 
 Apologies for that.
 Too bad we did not settled this situation earlier, but anyway, I am glad we 
 can discuss the change now.

 Still digging, I see you invited the Anima mailing list to discuss 
 that change as well. Feedback from Anima is very welcome. I mean, not 
 about the scopyness or not of a sentence, but rather on the value of the 
 algorithm for Anima. I see there were no reactions though.

 Now, concerning the correctness of this sentence. I think it can be proven 
 this way:

 1. Professionally managed networks are configured by the mean of human 
 configuration or by orchestrators.
 2. The prefix assignment algorithm can be configured with preferred 
 prefixes either by humans, or by orchestrators.
 Therefore: You can use the algorithm to configure a professionally managed 
 network.

 Example 1:
 The prefix assignment algorithm can be configured with static prefixes.
 Static and automatic assignments can even be done depending on the link or 
 the delegated prefix.
 For example, an enterprise could want part of the network to be 
 numbered statically, and another part of the network to be numbered 
 automatically.
 This is perfectly possible by configuring some links with preferred 
 assignment with a greater priority than auto-assigned prefixes.

 Example 2:
 Now, about your example of managed network with geographical constraints.
 Nodes executing the prefix assignment are allowed to *not* make assignments 
 from a given delegated prefix.
 Which means if you have two areas (A and B), and two delegated prefixes (X 
 and Y), nodes in A can be configured to only assign prefixes within X, and 
 nodes in B configured to only assign prefixes from Y.


 The prefix assignment algorithm is a network management tool enabling 
 auto-configuration *where you want it to happen*.
 It does not mandate auto-configuration (it does when used by HNCP, but that 
 is only one possible use of the prefix assignment algorithm).
 The document mostly explains:
 - The main detailed specification of the algorithm.
 - The rules that you MUST respect if you want the algorithm to work.

 And the thing is that about everything that does not create

[homenet] Objection to late change in draft-ietf-homenet-prefix-assignment

[Brian E Carpenter]

Hi,

Sorry to be so late with this but I had some personal distractions recently.

I am very surprised by a change that was made to this draft after IETF Last Call
and with no discussion, as far as I am aware, on the WG list. It is this
additional sentence in the first paragraph:

Although it does not require to be
configured to operate properly, it supports custom configuration by
means of variable priority assignments, and can therefore be used in
fully autonomic as well as professionally managed networks.

Firstly, this is a substantive change so I believe it should have been
discussed by the WG.

Secondly, the second half of the sentence seems completely unjustified, and
is way outside the Homenet context anyway. I believe that the range of
requirements for autonomic and/or professionally managed networks is far too
great to assert that variable priority assignments meet the needs; much
more general policy intent might be needed in autonomic networks, for
example, and the work on this topic is only just starting in Anima. As a
specific example, an international enterprise network might have geographical
requirements for prefix assignmnent.

Quite apart from the process issue, I believe that the second half of
the added sentence is wrong and must be deleted.

Regards
   Brian Carpenter


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

Re: [homenet] Border discovery without DHCP-PD

[Brian E Carpenter]

On 08/07/2015 09:31, Michael Richardson wrote:
 
 Brian E Carpenter brian.e.carpen...@gmail.com wrote:
  ... but I understand your desire to keep RAs off networks where they
  do not belong.  Perhaps RAs (and IPv6 prefix allocation) should be
  suppressed on networks on which no IPv6 traffic has been seen, and no
  RSs have ever occured.
 
  Once IPv4 is put out of its misery, that would be the null set,
  wouldn't it?
 
 Presence of RA(?I think?) or DHCPv6(PD) would cause the network to be seen as
 an external network, and would therefore turn off HNCP on that interface.

I don't see why RAs would do that. RAs are a required feature of an IPv6
network, regardless of whether it has external connectivity.

IMHO it would be perfectly OK for a router that comes up and finds itself
without any friends or uplinks to invent a ULA prefix and start RAs.

   Brian

 
 If some host is sending RSs and there are no RAs in answer, then the network
 may be waiting for HNCP to come up and provide service.
 
 --
 Michael Richardson mcr+i...@sandelman.ca, Sandelman Software Works
  -= IPv6 IoT consulting =-
 
 
 

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

Re: [homenet] Objection to late change in draft-ietf-homenet-prefix-assignment

[Brian E Carpenter]

Pierre,

Thanks for the prompt reply. I am not too worried about the process
issue, and I do understand why that whole paragraph was added (I've
added Meral in cc).

Your explanation is fine but the phrase and can therefore be used in
fully autonomic as well as professionally managed networks still makes
some big assumptions. How about and can therefore be used more
widely than in unmanaged home networks?

 I will be in Prague as well and would be happy to discuss whether PA could be 
 useful to Anima.

I can easily imagine an autonomic service agent (in Anima terminology)
using this algorithm (quite independent from whether it uses DNCP).

Regards
   Brian

On 08/07/2015 08:38, Pierre Pfister wrote:
 Hello Brian,
 
 This change was introduced after the Gen-ART review from Meral Shirazipour, I 
 quote:
   I found the draft a bit hard to follow as the incentive was not clear at 
 first. 
   A few sentences in abstract or introduction on 'why' we need this algorithm 
 and what would the 'alternatives' be would be useful. Right now it only says 
 'what' the algorithm does.
 
 This whole paragraph was therefore added:
This document specifies a distributed algorithm for automatic prefix
assignment.  The algorithm provides a generic alternative to
centralized (human or software based) approaches for network prefixes
and addresses assignment.  Although it does not require to be
configured to operate properly, it supports custom configuration by
means of variable priority assignments, and can therefore be used in
fully autonomic as well as professionally managed networks.
 
 Its purpose is to clarify the goal of the algorithm in a short sentence.
 
 Digging back into my mails, I realize that the exchange I had about this 
 update with Meral was private.
 My mistake, i thought the mailing list was cc’d to the discussion. Apologies 
 for that.
 Too bad we did not settled this situation earlier, but anyway, I am glad we 
 can discuss the change now.
 
 Still digging, I see you invited the Anima mailing list to discuss that 
 change as well. Feedback from
 Anima is very welcome. I mean, not about the scopyness or not of a sentence,
 but rather on the value of the algorithm for Anima. I see there were no 
 reactions though.
 
 Now, concerning the correctness of this sentence. I think it can be proven 
 this way:
 
 1. Professionally managed networks are configured by the mean of human 
 configuration or by orchestrators.
 2. The prefix assignment algorithm can be configured with preferred prefixes 
 either by humans, or by orchestrators.
 Therefore: You can use the algorithm to configure a professionally managed 
 network.
 
 Example 1:
 The prefix assignment algorithm can be configured with static prefixes.
 Static and automatic assignments can even be done depending on the link or 
 the delegated prefix.
 For example, an enterprise could want part of the network to be numbered 
 statically, and another part of the network to be 
 numbered automatically. 
 This is perfectly possible by configuring some links with preferred 
 assignment with a greater priority than auto-assigned prefixes.
 
 Example 2:
 Now, about your example of managed network with geographical constraints.
 Nodes executing the prefix assignment are allowed to *not* make assignments 
 from a given delegated prefix.
 Which means if you have two areas (A and B), and two delegated prefixes (X 
 and Y), nodes in A can be configured to only assign prefixes within X, and 
 nodes in B configured to only assign prefixes from Y.
 
 
 The prefix assignment algorithm is a network management tool enabling 
 auto-configuration *where you want it to happen*.
 It does not mandate auto-configuration (it does when used by HNCP, but that 
 is only one possible use of the prefix assignment algorithm).
 The document mostly explains:
 - The main detailed specification of the algorithm.
 - The rules that you MUST respect if you want the algorithm to work.
 
 And the thing is that about everything that does not create prefix collision 
 is, in the end, authorized.
 You could put anything as a configuration tool on top of PA, 
 from a netconf/Yang orchestrator to the usual linux ‘ip addr’ utility, or 
 even what the Anima working group could end-up specifying.
 
 I hope this helps with your concern about the correctness of this sentence.
 
 I will be in Prague as well and would be happy to discuss whether PA could be 
 useful to Anima.
 
 
 Thanks,
 
 - Pierre
 
 
 Le 7 juil. 2015 à 21:45, Brian E Carpenter brian.e.carpen...@gmail.com a 
 écrit :

 Hi,

 Sorry to be so late with this but I had some personal distractions recently.

 I am very surprised by a change that was made to this draft after IETF Last 
 Call
 and with no discussion, as far as I am aware, on the WG list. It is this
 additional sentence in the first paragraph:

 Although it does not require to be
 configured to operate properly, it supports custom configuration by
 means

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

[Brian E Carpenter]

Hi,

Stateless assignment based on Modified EUI64 interface identifiers
[RFC4291] SHOULD be used for address assignment whenever possible,

This is new and problematic. EUI64 is pretty much deprecated now, see
https://tools.ietf.org/html/draft-ietf-6man-ipv6-address-generation-privacy-07
(in IETF Last Call) for background, and https://tools.ietf.org/html/rfc7217
https://tools.ietf.org/html/draft-ietf-6man-default-iids-04 for
the way forward.

otherwise (e.g., for IPv4) the following method MUST be used instead:
For any assigned prefix for which SLAAC cannot be used, the first
quarter of the addresses are reserved for routers HNCP based address
assignments, whereas the last three quarters are left to the DHCPv6

That would only be acceptable, I think, if you also specify that pseudo-random
allocation is used within the 1/4 and 3/4 of the addresses (referring
to IPv6 only).

   Brian


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

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

[Brian E Carpenter]

On 06/07/2015 08:33, Dave Taht wrote:
 On Sun, Jul 5, 2015 at 12:57 PM, Brian E Carpenter
 brian.e.carpen...@gmail.com wrote:
 Hi,

Stateless assignment based on Modified EUI64 interface identifiers
[RFC4291] SHOULD be used for address assignment whenever possible,

 This is new and problematic. EUI64 is pretty much deprecated now, see
 https://tools.ietf.org/html/draft-ietf-6man-ipv6-address-generation-privacy-07
 (in IETF Last Call) for background, and https://tools.ietf.org/html/rfc7217
 https://tools.ietf.org/html/draft-ietf-6man-default-iids-04 for
 the way forward.
 
 Oy. One of the things I rely on is mark 1 eyeball when a device is
 renumbered, or has multiple ipv6 addresses. Recognizing the std SLAAC
 hex vomit pattern is VERY hard, but at least I can find things
 again
 
 Lacking any decent naming support is a real PITA when your lower level
 identifiers are random and changing all the time.

Yep. That is of course the intended effect from a privacy point of view.
I expect that enterprise network managers will hate it too.

Please not shoot messenger.

   Brian

otherwise (e.g., for IPv4) the following method MUST be used instead:
For any assigned prefix for which SLAAC cannot be used, the first
quarter of the addresses are reserved for routers HNCP based address
assignments, whereas the last three quarters are left to the DHCPv6

 That would only be acceptable, I think, if you also specify that 
 pseudo-random
 allocation is used within the 1/4 and 3/4 of the addresses (referring
 to IPv6 only).

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] 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 brian.e.carpen...@gmail.com a 
 écrit :

 On 29/06/2015 01:09, Pierre Pfister wrote:
 Hello,

 Le 28 juin 2015 à 10:58, Gert Doering g...@space.net 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 
 https://tools.ietf.org/html/draft-ietf-homenet-hncp-06#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 29/06/2015 01:09, Pierre Pfister wrote:
 Hello,
 
 Le 28 juin 2015 à 10:58, Gert Doering g...@space.net 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] WG Last Call for draft-ietf-homenet-dncp-03

[Brian E Carpenter]

Hi,

This is really just an FYI for the WG, not a direct comment on the draft.

The latest posted draft of the proposed Anima signalling protocol
is draft-carpenter-anima-gdn-protocol-03. It's by no means a WG draft
and big changes may be coming. However, the present draft attempts
to use a TLV format that is strictly compatible with DNCP, but needs
its own range of type codes.

Needless to say, I have read the DNCP draft, but don't have much new to
say about it.

Regards
   Brian Carpenter
On 07/05/2015 03:21, Mark Townsley wrote:
 Dear WG,
 
 Thank you for the recent reviews and update of draft-ietf-homenet-dncp.
 Please take the next 3 weeks to make your final reviews. WG Last Call will
 officially end on May 28.
 
 Thank you,
 
 - Mark and Ray
 
 
 On Thu, Mar 5, 2015 at 3:25 PM, Ray Bellis ray.bel...@nominet.org.uk
 wrote:
 

 Please provide further reviews for the recently updated
 draft-ietf-homenet-dncp and draft-ietf-homenet-hncp-04.  We believe these
 are very close to ready for WGLC.


 
 
 
 ___
 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-dncp-02.txt

[Brian E Carpenter]

Hi Markus,
On 23/04/2015 18:46, Markus Stenberg wrote:
 On 23.4.2015, at 2.37, Brian E Carpenter brian.e.carpen...@gmail.com wrote:
 1. Changed DNCP messages into series of TLV streams, allowing optimized 
 round-trip saving synchronization. 

 So, I have a couple of questions about the new text:

   A DNCP message in and of itself is just an abstraction; when using
   reliable stream transport, the whole stream of TLVs can be considered
   a single message, with new TLVs becoming gradually available once
   they have been fully received.  On datagram transport, each
   individual datagram is a separate message.  In order to facilitate
   fast comparing of local state with that in a received update, TLVs in
   every container TLV MUST be placed in ascending order based on the
   binary comparison of both TLV header and value.

 Firstly how do I know when I have received the end of the whole stream
 of TLVs? It's presumably not infinite, but with no clear notion of a
 “message how do I know when to stop processing?
 
 You can process TLVs invididually (the length is in second byte received), or 
 in small chunks. TLV processing definition has only one dependency on other 
 TLVs (node data has to have respective node state ’nearby’, for undefined 
 nearby) in the stream, and the node connection TLV must be remembered per 
 message (=whole TCP stream or single UDP datagram) if encountered.

OK, so the process will just keep running until the TCP session closes,
as I understand it. Which incidentally means that you tie up the listen port,
doesn't it? In GDNP we think of more transactional messages, which is why
I wasn't understanding DNCP properly.

 
 Any suggestions on how to rephrase that to be more clear?

Maybe you need an outline description of the DNCP state machine.

 
 Secondly, please define the phrase container TLV. It's quite unclear
 to me whether your model is simply a sequence of separate TLVs or
 whether TLVs are encapsulated, i.e. does the length field of the first
 TLV include the size of some embedded TLVs? Of course I could go and
 read the code to find out what you really mean, but this should really
 be specified at the beginning of section 7 “Type-Length-Value Objects.
 
 The later. I guess some sort of update is needed here.

Yes, it's not quite clear.

 
 Node Data TLV is the only container TLV in the base spec (but it only says 
 nested TLVs). The base spec has no other container TLVs.

OK.

 
 I noticed also that the Node Data TLV is missing a description. I guess it 
 only alludes to how it is encoded with the variable length, but that could 
 also just refer to the node identifier which is variable length in base spec 
 so clearly more detail is needed here.
 
 2. Added fragmentation extension for bigger node data and for chunking in 
 absence of reliable L2 and L3 fragmentation.
 Hmm. For GDNP we are thinking of simply saying use a conservative MTU
 and TLS” to avoid fragmentation.
 
 With TCP (=TLS) fragmentation isn’t a problem anyway for most part. Of 
 course, as our single node’s data is encoded (by default) in a single Node 
 Data TLV, that sets 2^16 size limit to it; that can be worked around using 
 the fragmentation scheme as well.

OK, that's clear now, thanks.

   Brian

 
 Thanks for the comments ;)
 
 Cheers,
 
 -Markus
 

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

Re: [homenet] I-D Action: draft-ietf-homenet-dncp-02.txt

[Brian E Carpenter]

Hi,

 1. Changed DNCP messages into series of TLV streams, allowing optimized 
 round-trip saving synchronization. 

So, I have a couple of questions about the new text:

   A DNCP message in and of itself is just an abstraction; when using
   reliable stream transport, the whole stream of TLVs can be considered
   a single message, with new TLVs becoming gradually available once
   they have been fully received.  On datagram transport, each
   individual datagram is a separate message.  In order to facilitate
   fast comparing of local state with that in a received update, TLVs in
   every container TLV MUST be placed in ascending order based on the
   binary comparison of both TLV header and value.

Firstly how do I know when I have received the end of the whole stream
of TLVs? It's presumably not infinite, but with no clear notion of a
message how do I know when to stop processing?

Secondly, please define the phrase container TLV. It's quite unclear
to me whether your model is simply a sequence of separate TLVs or
whether TLVs are encapsulated, i.e. does the length field of the first
TLV include the size of some embedded TLVs? Of course I could go and
read the code to find out what you really mean, but this should really
be specified at the beginning of section 7 Type-Length-Value Objects.

 2. Added fragmentation extension for bigger node data and for chunking in 
 absence of reliable L2 and L3 fragmentation.

Hmm. For GDNP we are thinking of simply saying use a conservative MTU
and TLS to avoid fragmentation.

Regards
   Brian Carpenter

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

Re: [homenet] Selecting a routing protocol for HOMENET

[Brian E Carpenter]

On 02/04/2015 16:34, Fred Baker (fred) wrote:
 My understanding, which could be wrong, is that the IESG has a long-standing 
 policy that a routing protocol needs to have two interoperable 
 implementations, written from the specification. It’s not about the SDO or 
 the specification (IS-IS anyone?), it’s about having proof that the 
 specification is in fact correct and implementable from, by having two or 
 more parties do it.

Formally, it's less rigid since RFC 4794, but the ADs have a lot of discretion.

   Brian

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

Re: [homenet] Selecting a routing protocol for HOMENET

[Brian E Carpenter]

On 01/04/2015 05:02, Joel M. Halpern wrote:
 Actually Ray, IETF process, as described by the IESG, happily allows for 
 Downref with suitable approval and notice to the
 community.  So, as far as I can tell, homenet could indeed reference and 
 mandate Babel in a Proposed Standard RFC.  I would
 agree that homenet choosing to do that would be a strong impetus for moving 
 the document to Standards track. But that does not
 have to be gating.

It doesn't. But otoh we'd like the protocol to meet the standards track criteria
in reality, not so much on paper (which is why the downref mechanism exists,
so that reality trumps bureaucracy). I actually like Dave Taht's point:
running code trumps theoretical extensibility.

So yes, I think the design team should be chartered to focus on technical
reality and to set aside bureaucratic requirements.

(But, since the interop that occurred last week - great to see that -
did apparently show up some minor issues, revving the Babel document
may be a good thing to do in any case.)

   Brian

 
 https://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry
 
 Yours,
 Joel
 
 On 3/31/15 11:54 AM, Ray Bellis wrote:

 On 31 Mar 2015, at 16:35, Dave Taht dave.t...@gmail.com wrote:

 I don't see any point in starting up a new working group[1] whatsoever
 based on the events of the last ietf homenet meeting, particularly
 with the arrival of a new written from-spec version of babel in under
 15 hours, (which I am still chortling about. I am tempted to write one
 in rust).

 Whilst full standardisation of Babel may end up happening in a WG anyway, 
 some of this design team's job will be to establish
 whether it's more expedient to bring Babel up to proposed standard levels 
 of specification than to add Homenet-related
 features (per your list below) to existing IETF endorsed standards.

 It is just punting the question and more delay when stuff that is more
 than sufficiently stable is done, already, and shipping, with a 5 year
 long productization pipeline left to fill.

 For better or worse, IETF process dictates that we cannot use what is 
 officially an _experimental_ protocol in a standards
 track document.  Markus' work was very impressive, but not sufficient to 
 overcome that hurdle.

 However this _should_ be a very short-lived punt - less than one IETF cycle. 
  The WG was unable to reach consensus over three
 full IETF cycles, and this structured design team approach _should_ clear 
 this log jam.

 (If it helps any (which I doubt) I have never thought that homenet
 must settle on one routing protocol, and certainly the from the ISP
 part of the link is underspecified)

 At least one routing protocol must be available, however to turn back
 the tide of the current situation where none are commonly available in
 most consumer routing gear. More than one IS available.

 We are arguing on the choice of one _mandatory to implement_ protocol.  For 
 interoperability's sake, this will be the one that
 must be available.

 Nothing can (nor will) prevent additional protocols from being implemented, 
 and perhaps even operate simultaneously.

 Aside from that my major two requirements have only been

 0) Must support source specific routing
 1) A homenet capable routing protocol MUST work well over wifi and
 wireless links in addition to conventional ethernet and other mac
 layers

 My minor requirements were:

 0) Binary and memory sizes must be small enough to fit into teeny routers
 1) should be wildly available in every off the shelf OS that might be
 used for routing
 2) should be extensively tested in environments ranging from homes, to
 battlemesh, to small business campus networks
 3) Should have a good spec, must have at least one open sourced and
 liberally licensed implementation

 These requirements are all very well understood.

 So to me, y'all are wasting time that could be better spent into A)
 pouring resources into making hnetd less the monster than it became,

 please elaborate (in a separate thread, please!)

 B) dogfooding what exists and C) developing better tests and D)
 developing better metrics

 PS However.

 [1] I would not mind a working group that took the outputs of the
 battlemesh folk (babel, olsr-ETX, batman, bmx) and stacked them up
 against the outputs of the ietf working groups (like RPL, olsrv2, and
 others from manet and elsewhere) - and the IEEE (like all the layer 2
 isis stuff) and that wg BOTH tackled them in the working group AND in
 the real world - and worked to sort out the mess of academic code and
 real world requirements in the hope, that one day, maybe before I die
 of old age and/or apoplexy, the one true routing protocol and metrics
 emerged from the chaos.

 If enough people backed that and a suitable charter was agreed that could 
 happen.

 kind regards,

 Ray

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

 
 

Re: [homenet] Selecting a routing protocol for HOMENET

[Brian E Carpenter]

On 27/03/2015 05:11, Terry Manderson wrote:

 For each
 highly plausible candidate routing protocol, the design team will
 estimate the work needed and the associated timeline to get an
 acceptable, full, standardized solution using each protocol. 

I suggest s/work/work and actions/.

Reason: The actions might include a liaison exchange with another
SDO, if it emerged that one of the candidates was not standardised
by the IETF and that it needed an update to its specification.
And the timeline would need to include the estimated time for
that liaison process and the other SDO's latency.

I also suggest that comments in this thread should consist of precise
proposed changes to the draft design team charter, not another run
round the whole discussion loop.

Brian

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

Re: [homenet] IEEE 1905.1 and 1905.1a

[Brian E Carpenter]

On 27/03/2015 11:44, Mikael Abrahamsson wrote:
 On Thu, 26 Mar 2015, STARK, BARBARA H wrote:
 
 I mentioned a couple of weeks ago that IEEE 1905.1 might be something 
 interesting to look at to see if it might be a useful
 component of a holistic homenet solution. It can do PHY and MAC layer 
 topology discovery and PHY-layer metrics, for all
 Ethernet MAC-based PHYs (including Wi-Fi, HomePlug, G.hn, MoCA, HomePNA, 
 Ethernet, etc.). Some feedback I got was that not
 being able to read the spec without paying for it made it a non-starter. 
 Which I completely agree with. I was talking to Pat
 Thaler, who knows a lot about IEEE, asking if there was some way to get the 
 specs to homenet. She said that if the homenet
 chairs sent a liaison to IEEE asking for it, explaining there was interest 
 in possibly referencing it, that IEEE might send
 over a copy that could be made available to homenet participants via a 
 password-protected means.

 So if there is interest, I'd be happy to volunteer to help make such a 
 liaison happen (work with chairs, liaison officer, and
 advocate on the IEEE side). I don't see any downside in asking for it.
 
 I am interested in this and would appreciate if it could be done.

+1, and there might be other WGs with a legitmate interest, so it
would be good if the agreement was flexible.

Brian

___
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] 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

[Brian E Carpenter]

On 25/03/2015 08:47, JF Tremblay wrote:
 
 On Mar 24, 2015, at 2:00 PM, Brian E Carpenter brian.e.carpen...@gmail.com 
 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.

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

[Brian E Carpenter]

As I said at the microphone today, I think that the explanations of
how the prefix-assignment and naming proposals will handle renumbering
are convincing. I also agree that there is no real distinction between
renumbering and a change of ISP (as far as prefixes and addresses are
concerned, of course), and that break-before-make renumbering could
come at any time due to an outage or ISP behaviour. 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.)

However, I am fairly convinced that this is not the whole story and that
in the ideal world some sort of orchestration process is needed. I did
look through the issues in RFC 7010 and RFC 5887, and fortunately most
of them are beside the point for homenets. 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:

0. Make sure that nobody ever even thinks about configuring
an IPv6 address manually (unless it's link-local, I suppose).

1. Warn users that renumbering is planned/has started.
(because long-living sessions will be affected, even in make-before-break)

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.

3. We also assume that a delegation or withdrawal will trigger the
appropriate action according to the future renumbering text in
the naming-architecture documents. Daniel's draft text says This section
details how the CPE is expected to handle renumbering...
Indeed, that is part of the orchestration process, but something
in the CPE is needed to trigger this (after triggering the PA process).

4. Hosts need new DNS server addresses. I'm not sure who causes
that to happen.

5. There may be unavoidable special cases (like informing firewalls
of new and deleted prefixes).

99. Inform users that renumbering has finished.

   Brian

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

[homenet] Reneumbering [ I-D Action: draft-ietf-homenet-naming-architecture-dhc-options-01.txt]

[Brian E Carpenter]

Daniel,
On 16/03/2015 14:48, Daniel Migault wrote:
 Hi,
 
 Thank you for the feed back. Here is an update of the renumbering section.
 I considered the two cases make-before-break and break-before-make.

Thanks very much for this. Coupled with Steven's answer about prefix
assignment, I think the main points are covered. It does seem that a
renumbering automaton will be needed in the CPE, to trigger both
processes.

Regards
Brian

 
 Feel free to make any comment.
 
 BR,
 Daniel
 

snip

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

Re: [homenet] Fwd: I-D Action: draft-ietf-homenet-naming-architecture-dhc-options-01.txt

[Brian E Carpenter]

 When a renumbering operation occurs, the CPE IP prefix is modified. As a
 result, IP addresses of the Homenet DNS(SEC) Zone are not valid anymore --
 as we assume the DNS(SEC) Homenet only has global reachable IP addresses.
 In addition, the Slave cannot anymore reach its master.

That seems to assume a break-before-make renumbering. The preferred
scenario is make-before-break, although we need to be able to support
both. I hope you can adjust the text to allow both.

Brian

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

Re: [homenet] prefix-assignment-03 [Reminder - WG Actions]

[Brian E Carpenter]

Pierre,

On 13/03/2015 20:33, Pierre Pfister wrote:
 Hello Brian,
 
 Please note that there’s only just under a week left on the WGLC for 
 draft-ietf-homenet-prefix-assignment-03.

 I find myself wondering how this algorithm will work during a 
 make-before-break
 renumbering procedure. Maybe it's obvious (but not to me ;-).
 
 In that case you would receive a new prefix not colliding with the previous 
 one.
 In the prefix assignment perspective, this new prefix is just a new delegated 
 prefix
 you should use for numbering you links. So the algorithm would use both and 
 you’d get one prefix
 per link for each of them. When the previous prefix gets removed, old 
 assigned prefixes 
 are removed too.

OK. It just wasn't obvious to me that PA could be used in that way.

 
 PA is just a general purpose distributed numbering algorithm. The way you 
 handle lifetimes is out
 of the scope of PA. But it surely is in the scope of HNCP (ietf-homenet-hncp).
 
 HNCP attaches the preferred and valid lifetimes to each delegated prefix, 
 which are in turn provided to the hosts by the
 mean of RAs.
 In the make-before-break case, PA numbers the links with the new prefix 
 before removing the prefixes associated with the old one.
 It let hosts renumber gracefully based on preferred lifetime values.

Right. So the next question is: what will trigger HNCP to start this
process? RFC 4192 seems to assume a guiding intelligence performing a
careful sequence of actions.

Thanks
Brian

 
 
 Cheers,
 
 - Pierre
 
 
 

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

[homenet] prefix-assignment-03 [Reminder - WG Actions]

[Brian E Carpenter]

On 11/03/2015 23:19, Ray Bellis wrote:
 Please note that there’s only just under a week left on the WGLC for 
 draft-ietf-homenet-prefix-assignment-03.

I find myself wondering how this algorithm will work during a make-before-break
renumbering procedure. Maybe it's obvious (but not to me ;-).

Break-before-make doesn't confuse me, because it amounts to destroying
all prefixes and starting again. But we don't want to encourage that
approach.

   Brian

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

Re: [homenet] Stub networks

[Brian E Carpenter]

Juliusz,

I like your analysis, and I think it needs to be included in a
homenet document. It doesn't really belong in the routing
protocol comparison, although it may call for some requirements
for router implementations. Maybe there is a homenet router
requirements draft in our future.

Regards
   Brian

On 07/03/2015 12:56, Juliusz Chroboczek wrote:
 But now I don't see what's to stop a home user from buying a more
 general-purpose router which happens to have a ZigBee port or something,
 and plugging it in such a way that it *should* behave as a stub router.
 How does it discover that and configure itself accordingly?
 
 Disclaimer: I know nothing about ZigBee.
 
 My first reaction is that we'll cross that bridge when we come to it.
 
 My second reaction is that in a properly functioning network, the ordinary
 mechanisms of the routing protocol will effectively treat the link as
 a stub.  If the topology is just
 
 
Homenet --- A 
  (ZigBee)
 
 then obviously the ZigBee link will not be used for transit.  If the
 topology is redundant:
 
Homenet --- A -- B
||
||
C .. D
 (ZigBee)
 
 then the routing protocol should assign a sufficiently high metric to the
 ZigBee link, so that in effect it will be treated as a stub link.
 (Disclaimer: the current implementation of Babel doesn't do that yet, it
 currently only has a taxonomy of wired/wireless/bridged/BATMAN, I'm quite
 willing to implement it if somebody has a suitable device to test on.)
 
 Where you run into trouble is when the Homenet topology is not redundant
 enough, and there is a fault on the Homenet side:
 
Homenet --- AB
||
||
C .. D
 (ZigBee)
 
 Here, no matter how high the metric of the ZigBee link, Homenet traffic
 from A to B will want to go through it.  If A is your NAS and B is your
 TV, then an attempt to start a streaming session may bring the ZigBee link
 to its knees.
 
 My third reaction is that this should be avoided by proper AQM on the
 ZigBee link, but I don't know anything about AQM for ZigBee, so I'll shut
 up.
 
 So in summary, the stub functionality is only necessary when (1) the
 topology is redundant, (2) the ZigBee link doesn't have adequate AQM, and
 (3) the ZigBee link needs to remain functional even when the Homenet gets
 otherwise partitioned.  While I agree that there are useful use cases for
 that (you certainly want your thermostat to keep functioning even when
 somebody unplugged the Ethernet from your television), frankly, I'm not
 going to loose too much sleep over that.
 
 -- Juliusz
 

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

Re: [homenet] Stub networks [draft-mrw-homenet-rtg-comparison-02.txt]

[Brian E Carpenter]

On 07/03/2015 01:02, Ray Hunter wrote:
 Juliusz Chroboczek wrote:
 Or more generally, how does a stub router know that it's a stub router,
 when there is no human to tell it so?

 Yeah, it's not very clear.  We were actually asked to describe the two
 protocols' support for stub networks, and nobody never told us which of
 the many definitions of stub network they meant, let alone describing the
 use case precisely.  (The document uses the same definition as Cisco's
 EIGRP documentation, in case you're interested.)

 I'm imagining a dedicated device that has both a WiFi interface and
 a low-power interface that acts as a gateway between the Homenet network
 and the sensor network.  Such a device would come from the factory with
 the low power interface configured as a stub.

 -- Juliusz



 
 Good points.
 
 My idea of a stub router is that the stub router itself knows it is a stub 
 router.

I thought for about 24 hours that this was indeed the answer to my question.
Well, it is, for routers that are designed, packaged, labelled and shipped
for a stubby purpose such as managing a bunch of thermostats or something.
What Ray says below applies to this case.

But now I don't see what's to stop a home user from buying a more
general-purpose router which happens to have a ZigBee port or something,
and plugging it in such a way that it *should* behave as a stub router.
How does it discover that and configure itself accordingly?

Saying that the user made a mistake or should have configured the
device is not an answer.

   Brian

 
 Someone somewhere has said that this device will not forward packets on 
 behalf of other devices.
 Whether that's in the factory e.g. it runs a special version of the routing 
 daemon, or because the device has been configured by
 the owner as a multi-homed host.
 
 classic stub routers in EIGRP and IS IS are generally used to save bandwidth/ 
 improve convergence times/ reduce memory
 utilisation/ improve route table stability on remote sites.
 
 The main use case in Homenet that I have in mind is so that the stub device 
 can advertise a stable loopback or other interface
 whilst changing it's attachment point to the rest of the homenet e.g. wifi 
 roaming.
 
 With those definitions in mind, I see little difference between a route 
 filter configured on the full-blown homenet routers, and
 a route filter configured on the stub router device itself.
 
 Given the stub router knows it's a stub router (by a mechanism outside of 
 hnet or babel or IS IS), the obvious preference would
 be for any filters to be set up on the stub router itself.
 
 e.g. use case of roaming node + stable addresses of other interfaces
 outbound route advertisement filter =
 permit directly connected interfaces
 deny any
 
 The list of directly connected interfaces can be easily automated without 
 user intervention.
 
 And if the use case is to preserve memory utilisation on small devices
 inbound route advertisement filter on upstream interface to homenet =
 permit default route
 deny any
 
 outbound route advertisement filter on upstream interface to homenet =
 permit summary of all prefixes behind my downstream interface
 deny any
 
 the list of prefixes downstream is also known locally.
 

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

[homenet] Stub networks [draft-mrw-homenet-rtg-comparison-02.txt]

[Brian E Carpenter]

Hi,

 8.  Support for Stub Networks and Stub Routers
...
IS-IS supports stub-networks as defined above
simply by advertising the prefix associated with a link, but not the
link itself.  This is sometimes referred to as a passive link.
 
Further an IS-IS router has the ability to set a bit (the overload
bit) to indicate that it should not be used for any transit traffic,
and that it will only be considered a destination for the prefixes it
has advertised, i.e., it is a stub router as defined above.
...
As all distance vector protocols, Babel supports fairly arbitrary
route filtering.  Designating a stub network is done with two
statements in the current implementation's filtering language.

In a homenet, there must be no manual config. In both cases, how does
this work automatically? How does IS-IS know not to advertise the link
and set the overload bit, and how does Babel know to include those
filtering rules? Or more generally, how does a stub router know that
it's a stub router, when there is no human to tell it so?

Regards
   Brian

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

Re: [homenet] Stub networks [draft-mrw-homenet-rtg-comparison-02.txt]

[Brian E Carpenter]

On 06/03/2015 09:19, Acee Lindem (acee) wrote:
 
 
 On 3/5/15, 2:46 PM, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr
 wrote:
 
 Or more generally, how does a stub router know that it's a stub router,
 when there is no human to tell it so?

 Yeah, it's not very clear.  We were actually asked to describe the two
 protocols' support for stub networks, and nobody never told us which of
 the many definitions of stub network they meant, let alone describing the
 use case precisely.  (The document uses the same definition as Cisco's
 EIGRP documentation, in case you're interested.)

 I'm imagining a dedicated device that has both a WiFi interface and
 a low-power interface that acts as a gateway between the Homenet network
 and the sensor network.  Such a device would come from the factory with
 the low power interface configured as a stub.
 
 It is my understanding that this is the use case for auto-configured stub
 routers as well. They are constrained devices that are only capable acting
 as a stub router. 

Yes, the idea that this an intrinsic property of certain devices
makes sense to me. If I buy a home climate control system that includes
a router to connect it to the rest of the homenet, it can know that
it's a stub router out of the box. What doesn't work for me is any
suggestion that somebody needs to configure this, because in 99% of
homes that isn't going to happen. The text in the draft could be a bit
clearer on this point.

Thanks
   Brian

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

Re: [homenet] Stub networks [draft-mrw-homenet-rtg-comparison-02.txt]

[Brian E Carpenter]

On 06/03/2015 08:36, Christian Hopps wrote:
 
 On Mar 5, 2015, at 2:27 PM, Brian E Carpenter brian.e.carpen...@gmail.com 
 wrote:

 Hi,

 8.  Support for Stub Networks and Stub Routers
 ...
   IS-IS supports stub-networks as defined above
   simply by advertising the prefix associated with a link, but not the
   link itself.  This is sometimes referred to as a passive link.

   Further an IS-IS router has the ability to set a bit (the overload
   bit) to indicate that it should not be used for any transit traffic,
   and that it will only be considered a destination for the prefixes it
   has advertised, i.e., it is a stub router as defined above.
 ...
   As all distance vector protocols, Babel supports fairly arbitrary
   route filtering.  Designating a stub network is done with two
   statements in the current implementation's filtering language.

 In a homenet, there must be no manual config. In both cases, how does
 this work automatically? How does IS-IS know not to advertise the link
 and set the overload bit, and how does Babel know to include those
 filtering rules? Or more generally, how does a stub router know that
 it's a stub router, when there is no human to tell it so?
 
 For IS-IS, the stub router would know so b/c it can’t be anything else. It is 
 running the stub version of the software. The reason it would be doing this 
 is b/c it’s a very small device not designed to do anything else.
 
 BTW, is it true that there must be no manual config, or simply that one 
 cannot rely on manual config?

IMHO the second case applies - manual config may be possible, but
the network must run correctly without it.

   Brian

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

Re: [homenet] 6renum redux [Routing protocol comparison document]

[Brian E Carpenter]

On 04/03/2015 22:22, Ole Troan wrote:
 Much as I love MPTCP, it only helps TCP sessions. And it requires both
 hosts to
 be updated to be effective.
 
 IPv6 multi-prefix multi-homing requires both hosts to support it. which means 
 transport fixes.

Or fully operational shim6, which was conceived and designed for this
exact problem.

   Brian

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

Re: [homenet] 6renum redux [Routing protocol comparison document]

[Brian E Carpenter]

On 04/03/2015 23:12, Ole Troan wrote:
 Much as I love MPTCP, it only helps TCP sessions. And it requires both
 hosts to
 be updated to be effective.

 IPv6 multi-prefix multi-homing requires both hosts to support it. which 
 means transport fixes.
 
 to reply to myself. is anyone aware of any document describing the 
 expectations for hosts / host gaps with regards to IPv6 multi-prefix 
 multi-homing? including renumbering, mobility, redundancy, load sharing... 
 essentially the RFC3582 goals.

The best I've got is the set of MULTI6 deliverables:

Goals for IPv6 Site-Multihoming Architectures (RFC 3582)
IPv4 Multihoming Practices and Limitations (RFC 4116)
Architectural Approaches to Multi-Homing for IPv6 (RFC 4177)
Threats relating to IPv6 Multihoming Solutions (RFC 4218)
Things Multihoming in IPv6 (MULTI6) Developers Should Think About (RFC 4219)

   Brian

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

Re: [homenet] 6renum redux [Routing protocol comparison document]

[Brian E Carpenter]

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



On 04/03/2015 05:54, Mikael Abrahamsson wrote:
 On Tue, 3 Mar 2015, Ray Hunter wrote:
 
 I think there are two completely separate mechanisms being discussed
 here: the need for rapid failover to a previously known alternative
 address for your partner device, and discovering the alternative
 addresses of your partner.
 
 Agree.
 
 The one thing I think that is still missing in the discussion is
 caching in the name space. Whether name resolution of the remote
 partner address be done via mDNS, DNS, or monitoring the currently
 established channel between partner nodes like in shim6, whatever.
 
 I think we need this done via the existing channel, a la MP-TCP and SHIM6.

Much as I love shim6, it's currently a broken solution because most
firewalls
drop packets with shim6 extension headers. And it requires both hosts to
be updated to be effective.

Much as I love MPTCP, it only helps TCP sessions. And it requires both
hosts to
be updated to be effective.

   Brian

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

Re: [homenet] routing protocol comparison document and hncp

[Brian E Carpenter]

On 03/03/2015 09:12, Michael Thomas wrote:
 On 03/02/2015 11:54 AM, Brian E Carpenter wrote:
 On 03/03/2015 08:38, Michael Thomas wrote:
 Well, draft-pritikin-anima-bootstrapping-keyinfra-01 describes a way
 to bootstrap a certificate infrastructure, zero touch. Once every
 device in a domain has a domain certificate, two devices can directly
 authenticate each other, without PSK. Then you can also authenticate a
 key negotiation scheme such as IKE, to negotiate a PSK which you can
 then use in your normal authentication scheme. Obviously, would be
 nice if protocol supported certs directly, but it's not required.

 I still think that the above draft is a very good way to bootstrap a
 certificate infrastructure, which can be leveraged in many different
 ways.


 I'm doubtful that routing protocols need PSK's. They almost certainly
 would like to share a symmetric key(s) but
 is not the same thing.
 But they need to agree on the shared key(s) securely, and the only way
 I know how to do that zero-touch is by starting with asymmetric keys
 and certificates.


 s/and certificates//

Well, I want certificates, because I don't believe someone who
says Hi, I'm your friendly homenet router and here's my public
key.

   Brian

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

Re: [homenet] 6renum redux [Routing protocol comparison document]

[Brian E Carpenter]

Hi Toerless,
On 03/03/2015 10:23, Toerless Eckert wrote:
 Would any of those rfc explain to me what the problems with renumbering
 in a homenet are that Fave tried to avoid by doing NAT ? And how
 those issues can not be mitigated by better workarounds than NAT ?

http://tools.ietf.org/html/rfc7010 is the gap analysis, but for
enterprise networks. I think what Dave is actually saying is that
complex home networks of the future (which is where he already lives)
inherit many of these problems, with difference that renumbering
will be imposed by the ISP, so the element of choice and planning
that an enterprise network has is missing.

Somebody needs to work on RFC7010-for-homenet, I guess.

(Curtis is right, of course: if a network is designed and
managed with renumbering treated as an expected event, life
would be better.)

Brian

 
 On Sun, Mar 01, 2015 at 02:24:08PM +1300, Brian E Carpenter wrote:
 Admittedly 6renum was targetted at enterprise networks, partly because
 of the
 observation that homenets renumber anyway after every power cut. But
 we have spent a lot of cycles on this issue.

 http://tools.ietf.org/html/rfc4192
 http://tools.ietf.org/html/rfc5887
 http://tools.ietf.org/html/rfc6866
 http://tools.ietf.org/html/rfc6879
 http://tools.ietf.org/html/rfc7010
 and maybe it's time to revive
 https://tools.ietf.org/html/draft-liu-opsarea-ipv6-renumbering-guidelines

Brian


 On 01/03/2015 12:40, Curtis Villamizar wrote:
 In message 
 caa93jw4tumfm_lvzkrx7ark2z+hwtw5jboenpvfejut4l9t...@mail.gmail.com
 Dave Taht writes:
  
 On Fri, Feb 27, 2015 at 2:00 PM, Curtis Villamizar
 cur...@ipv6.occnc.com wrote:
 In message 54ee258e.8060...@gmail.com
 Brian E Carpenter writes:

 On 26/02/2015 05:14, Mikael Abrahamsson wrote:
 On Wed, 25 Feb 2015, Ray Hunter wrote:

 That way the devices can roam at L3, without all of the nasty side 
 effects of re-establishing TPC sessions, or updating
 dynamic naming services, or having to run an L2 overlay network 
 everywhere, or having to support protocols that require a
 specialised partner in crime on the server side (mTCP, shim6 et al).

 It's my firm belief that we need to rid clients of IP address 
 dependence for its sessions. Asking clients to participate in HNCP
 only addresses the problem where HNCP is used.

 Fixing this for real would reap benefits for devices moving between any 
 kind of network, multiple providers, mobile/fixed etc.

 Violent agreement. This is not a homenet problem; it's an IP problem.
 In fact, it's exactly why IP addresses are considered harmful in
 some quarters. Trying to fix it just for homenet seems pointless.
 http://www.sigcomm.org/ccr/papers/2014/April/000.008

Brian


 Brian,

 Seriously - your paper may be overstating the problem.  At least if we
 discount IPv4 and in doing so eliminate NAT we solve a lot of problems
 that never should have existed in the first place.  If we carry NAT
 over to IPV6, then shame on us.
  
 I am sorry, I no longer share this opinion. The pains of renumbering
 someones entire home network every time the ISP feels like it, given
 the enormous number of devices I have encountered that don't handle it
 well, are just too much to bear.

 I renumbered 140.222/16 into 147.225/16 in the mid 1990s (T3-NSFNET to
 ANSNET as part of the NSFNET decommissioning).  Not by myself of
 course, but there were only a few of us on this.  It wasn't all that
 bad and we had about 2,000 things to renumber in hundreds of
 locations, many of them not manned.  Shell scripts and ksh (kerberized
 rsh, not the Korn shell) made it simpler.  The worst was Cisco routers
 and various old DSU/CSU and other commercial stuff since you had to
 use expect scripts on their CLI rather than just something of the
 form ksh fqdn -l root ifconfig newaddr/mask alias People with root
 on their workstation that didn't give us acess were given notice.  We
 used interface aliases and gradually took down the old aliases and
 subnet addresses.  Nothing critical was affected.  It took a day or
 two, then bake time, then less than a day to remove aliases.

 OTOH - Most homes can't run two prefixes for a week or two before
 taking the old prefix down.  And lots of consumer devices don't do
 aliases.  But now days there is DHCP which didn't exist then (and
 ICMPv6 RS/RA and SLAAC).

 Are you having problems with the provider not giving you a static IPv6
 prefix, but rather changing it on a whim?

 I also renumbered my home net multiple times, but again, not much
 pain.  Only a few consumer gadgets here have fixed addresses (one
 because it never renewed DHCP leases and therefore needed a fixed
 address, but that has since been tossed in e-waste recycling).

 The next version of cerowrt will do translation from the external IPv6
 address range to a static internal one (or ones, in the case of
 multiple egress gateways), and lacking a standard for such will use
 fcxx/8 addressing. I will make it be an option for people to turn off

Re: [homenet] routing protocol comparison document and hncp

[Brian E Carpenter]

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



On 03/03/2015 15:05, Michael Thomas wrote:
 On 03/02/2015 01:21 PM, Brian E Carpenter wrote:
 On 03/03/2015 09:12, Michael Thomas wrote:
 
 I'm doubtful that routing protocols need PSK's. They almost
 certainly would like to share a symmetric key(s) but is not the
 same thing.
 But they need to agree on the shared key(s) securely, and the
 only way I know how to do that zero-touch is by starting with
 asymmetric keys and certificates.
 
 
 s/and certificates//
 Well, I want certificates, because I don't believe someone who says
 Hi, I'm your friendly homenet router and here's my public key.
 
 
 so you're mollified if somebody's cert says hi i'm 
 1232345245213452345...@lkajsdlfjasdfds.clasjdflakjsdfk.ladsjflakjsfdls.xxx
 instead?
 the possession of a cert does nothing in and of itself to make an 
 enrollment decision.

No, of course not. That is the whole point of using
draft-pritikin-anima-bootstrapping-keyinfra or an equivalent.

Brian

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

[homenet] 6renum redux [Routing protocol comparison document]

[Brian E Carpenter]

Admittedly 6renum was targetted at enterprise networks, partly because
of the
observation that homenets renumber anyway after every power cut. But
we have spent a lot of cycles on this issue.

http://tools.ietf.org/html/rfc4192
http://tools.ietf.org/html/rfc5887
http://tools.ietf.org/html/rfc6866
http://tools.ietf.org/html/rfc6879
http://tools.ietf.org/html/rfc7010
and maybe it's time to revive
https://tools.ietf.org/html/draft-liu-opsarea-ipv6-renumbering-guidelines

   Brian


On 01/03/2015 12:40, Curtis Villamizar wrote:
 In message 
 caa93jw4tumfm_lvzkrx7ark2z+hwtw5jboenpvfejut4l9t...@mail.gmail.com
 Dave Taht writes:
  
 On Fri, Feb 27, 2015 at 2:00 PM, Curtis Villamizar
 cur...@ipv6.occnc.com wrote:
 In message 54ee258e.8060...@gmail.com
 Brian E Carpenter writes:

 On 26/02/2015 05:14, Mikael Abrahamsson wrote:
 On Wed, 25 Feb 2015, Ray Hunter wrote:

 That way the devices can roam at L3, without all of the nasty side 
 effects of re-establishing TPC sessions, or updating
 dynamic naming services, or having to run an L2 overlay network 
 everywhere, or having to support protocols that require a
 specialised partner in crime on the server side (mTCP, shim6 et al).

 It's my firm belief that we need to rid clients of IP address dependence 
 for its sessions. Asking clients to participate in HNCP
 only addresses the problem where HNCP is used.

 Fixing this for real would reap benefits for devices moving between any 
 kind of network, multiple providers, mobile/fixed etc.

 Violent agreement. This is not a homenet problem; it's an IP problem.
 In fact, it's exactly why IP addresses are considered harmful in
 some quarters. Trying to fix it just for homenet seems pointless.
 http://www.sigcomm.org/ccr/papers/2014/April/000.008

Brian


 Brian,

 Seriously - your paper may be overstating the problem.  At least if we
 discount IPv4 and in doing so eliminate NAT we solve a lot of problems
 that never should have existed in the first place.  If we carry NAT
 over to IPV6, then shame on us.
  
 I am sorry, I no longer share this opinion. The pains of renumbering
 someones entire home network every time the ISP feels like it, given
 the enormous number of devices I have encountered that don't handle it
 well, are just too much to bear.
 
 I renumbered 140.222/16 into 147.225/16 in the mid 1990s (T3-NSFNET to
 ANSNET as part of the NSFNET decommissioning).  Not by myself of
 course, but there were only a few of us on this.  It wasn't all that
 bad and we had about 2,000 things to renumber in hundreds of
 locations, many of them not manned.  Shell scripts and ksh (kerberized
 rsh, not the Korn shell) made it simpler.  The worst was Cisco routers
 and various old DSU/CSU and other commercial stuff since you had to
 use expect scripts on their CLI rather than just something of the
 form ksh fqdn -l root ifconfig newaddr/mask alias People with root
 on their workstation that didn't give us acess were given notice.  We
 used interface aliases and gradually took down the old aliases and
 subnet addresses.  Nothing critical was affected.  It took a day or
 two, then bake time, then less than a day to remove aliases.
 
 OTOH - Most homes can't run two prefixes for a week or two before
 taking the old prefix down.  And lots of consumer devices don't do
 aliases.  But now days there is DHCP which didn't exist then (and
 ICMPv6 RS/RA and SLAAC).
 
 Are you having problems with the provider not giving you a static IPv6
 prefix, but rather changing it on a whim?
 
 I also renumbered my home net multiple times, but again, not much
 pain.  Only a few consumer gadgets here have fixed addresses (one
 because it never renewed DHCP leases and therefore needed a fixed
 address, but that has since been tossed in e-waste recycling).
 
 The next version of cerowrt will do translation from the external IPv6
 address range to a static internal one (or ones, in the case of
 multiple egress gateways), and lacking a standard for such will use
 fcxx/8 addressing. I will make it be an option for people to turn off,
 but I've had it with being renumbered.
 
 Are you suggesting that we add NAT to IPv6?  [I ask with disbelief.]
 
 I would definitely be turning that off since I have a plenty big and
 very static IPv6 prefix.  I also have a (tiny) static IPv4 prefix so I
 have no choice but to IPv4 NAT due to its tiny size.
 
 A better option might be to use something that switches over faster
 than a DHCP lease times of days.  It seems that ICMPv6 RA can be sent
 with prefix prefix information TLV with valid lifetime and/or
 preferred valid lifetime of zero.  This is in RFC 4861 on Page 55:
 
   - If the prefix is already present in the host's Prefix List as
 the result of a previously received advertisement, reset its
 invalidation timer to the Valid Lifetime value in the Prefix
 Information option.  If the new Lifetime value is zero, time-out
 the prefix immediately (see Section 6.3.5

Re: [homenet] Routing protocol comparison document

[Brian E Carpenter]

On 26/02/2015 05:14, Mikael Abrahamsson wrote:
 On Wed, 25 Feb 2015, Ray Hunter wrote:
 
 That way the devices can roam at L3, without all of the nasty side effects 
 of re-establishing TPC sessions, or updating
 dynamic naming services, or having to run an L2 overlay network everywhere, 
 or having to support protocols that require a
 specialised partner in crime on the server side (mTCP, shim6 et al).
 
 It's my firm belief that we need to rid clients of IP address dependence for 
 its sessions. Asking clients to participate in HNCP
 only addresses the problem where HNCP is used.
 
 Fixing this for real would reap benefits for devices moving between any kind 
 of network, multiple providers, mobile/fixed etc.

Violent agreement. This is not a homenet problem; it's an IP problem.
In fact, it's exactly why IP addresses are considered harmful in
some quarters. Trying to fix it just for homenet seems pointless.
http://www.sigcomm.org/ccr/papers/2014/April/000.008

   Brian

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

Re: [homenet] DNCP questions

[Brian E Carpenter]

On 25/02/2015 21:15, Markus Stenberg wrote:
 On 25.2.2015, at 0.56, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr 
 wrote:
 should not send packets larger than 1500 octets unless it has assurance
 that the destination is capable of reassembling packets of that larger
 size.
 I guess this is another MUST to be added to HNCP text (DNCP itself is
 not IPv6-specific as such).
 You mean that every HNCP node MUST ba able to accept packets of up to 64kB?
 What’s the status of typical embedded stacks?
 
 Configuration dependant more than implementation at least in the few I have 
 played with, but usually they’re really short of RAM so usually configuration 
 is rather conservative. Sticking (say) DTLS in one is probably no-go due to 
 lack of computing power to start with so I am not sure this is that relevant.
 
 That said, from my point of view, if this is really thought to be an issue by 
 the WG, correct solution is to use TLS (+TCP) instead of DTLS (+UDP) in any 
 case.

I've thought about this in the Anima/GDNP context and reached the
same conclusion. Why make life complicated when TLS makes it simple?

   Brian

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

Re: [homenet] A poll

[Brian E Carpenter]

On 21/02/2015 05:50, Dave Taht wrote:

 So a quick poll:

Goodie, I love polls (not) ;-)

 0) Have you managed to get ipv6 working at all? If so, how? What sort
 of problems did you encounter?

Yes.

(a) Using SixXs/ayiya. Geek problems (the SixXs geeky registration
interface, and the fact that installation is definitely not for
the general public). But it works very reliably for a single host.

(b) With my current ISP, native dual stack service via a FritzBox.
Worked out the box. Until it didn't, when the ISP admitted to switching
IPv6 off without warning due to unspecified issues with some customers.
Then they switched it on again without explanation, and it works fine
again. [Probably, the issue was MTU size problems with a well-known
CDN's nearest POP, which was across the Tasman Sea at the time; compounded
by Google's recent bad hair week.]

I've gone into detail there because for more than a year, my wife was
using IPv6 without knowing it (on Windows 8). But when the above mentioned
problems occurred, she noticed PDQ and did not have SixXs to fall back
on. So we had to disable IPv6 on her machine. Happy Eyeballs did *not*
conceal the problem.

 1) Have you attempted to deploy a routing protocol in your home? Which
 one, and why?

No, sorry, only one link here.

 2) Have you attempted to get hnetd's prefix distribution system
 working? (it supports linux mainline and openwrt presently)

No

 3) Do you use ethernet? How many clients in your home are ethernet connected?

Normally zero. I would plug in if I hit wireless issues.

 4) Do you use wifi? How many clients are wifi connected? 

Two to four (house guests get free Wi-Fi ;-). My ancient
printer refuses to break, so that is hard wired to a computer.

 Do you use range extenders?

No

 5) How many devices do you think you will have connected to the
 network in your home in 5 years?

Let's guess 10. But the interesting questions are how many
routers, and will it be dual-homed.

 How many now?
 
 6) Do you use any other network connected technologies (homeplug,
 802.14, LTE, etc). If so, which ones, and why?

No.

 7) Do you use mdns service discovery?

No

 8) Why are you here? (especially, if your answers to 0-2, are no)

http://tools.ietf.org/html/rfc3935

   Brian

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

[homenet] Homenets and MPVD

[Brian E Carpenter]

Hi,

I find myself wondering how draft-ietf-homenet-prefix-assignment
and draft-ietf-homenet-hncp will be reconciled with the MIF
MPVD architecture
(http://datatracker.ietf.org/doc/draft-ietf-mif-mpvd-arch/).
Has anybody thought about that yet?


Regards
   Brian

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

Re: [homenet] sorting out the right ipv6 addr to choose and name in a source specific world

[Brian E Carpenter]

On 23/12/2014 03:22, Gert Doering wrote:
 Hi,
 
 On Mon, Dec 22, 2014 at 03:18:47PM +0100, Juliusz Chroboczek wrote:
 If you have two hosts connected at different places to the same mesh
 network, they could have very different performance characteristics while
 having addresses from the same /64.
 
 Indeed, that's the other end of the diversity spectrum (vs. all hosts in
 our /32 have roughly the same network characteristics).

Yes. But this whole thing is a heuristic anyway; I could imagine
quite sophisticated algorithms, or something fairly simple such
as cache results for a pair of /64s; if that gives inconsistent
RTTs, cache results for individual pairs of /128s.

   Brian

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

Re: [homenet] sorting out the right ipv6 addr to choose and name in a source specific world

[Brian E Carpenter]

On 22/12/2014 08:44, Juliusz Chroboczek wrote:
 You might also need to combine the features of the gateway with the
 metric(s) of the path to the gateway.
 
 I do end-to-end measurements in my mosh implementation, so we should
 not have the problem.
 
 Does this really scale well?
 
 How well do we need it to scale?  Three addresses per host?  A dozen?
 A hundred?  (Per host, mind you -- not per router.)
 
 The probes Matthieu's code is sending are less than 90 bytes each.  This
 means that if the client and the server have three addresses each, each
 probing episode consists of a burst of 9 packets totalling less than one
 full Ethernet frame.  (18 if you count the replies.)
 
 On the other hand, if we end up having hundreds of addresses on every
 host, the strategy will need to be rethought.  Dave is currently playing
 with a network where each host has 10 addresses of different kinds, and
 he's trying to work out heuristics to limit the number of probes.  I'd
 personally prefer to gather some empirical data before we start optimising
 things.

A good thought. From the point of view of usefulness, more than two or
three addresses per host seems pretty pointless (that is at any rate
what draft-naderi-ipv6-probing told us). Probe results should probably
be cached for a while and interpreted per-prefix not per-address.

   Brian

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

Re: [homenet] sorting out the right ipv6 addr to choose and name in a source specific world

[Brian E Carpenter]

On 19/12/2014 04:07, Michael Richardson wrote:
 
 Dave,
 my take is that applications, and the entire gai.conf/getaddrinfo() library
 is broken.  Applications can neither be updated nor be trusted to know enough
 about the system to be able to make a proper decision.
 
 Somewhere, someone was working on a new connect(2) call that took FQDNs
 rather than sockaddr's, such that the kernel could take ownership of this
 problem. 

I suppose you are thinking of Name Based Sockets:
http://tools.ietf.org/html/draft-ubillos-name-based-sockets

It's dead, as far as I know.

 (Of course, actually solving the problem in a kernel is probably the
 wrong answer).
 What is necessary is some new infrastructure inside the box which becomes
 standardized (like sockets API was), with some daemon that thinks about the
 best source addresses is, and possibly gets involved with routing protocols.
 (I'm told that OSX has a sophisticated state machine that combines DHCP and
 1x, and wifi... it sounds like it could be the start of such a thing)
 
 I think that shim6 and mptcp are answers in this equation.
 
 shim6 has, I'm told, deployment issues which make me very very sad.

Like, it cannot get through most firewalls.

 mptcp, I'm told, is likely to show up in Apple and Google products and
 infrastructure, and my idea (and many others) is that you don't always have
 to pick the perfect address for the SYN, just one that works, but rather one
 can add better addresses as one discovers them.

But bad luck if you need UDP.

Some form of intelligent probing does seem to be the answer,
but certainly that needs to be generic because we cannot expect
all apps developers to reinvent it. That's one reason we wrote
http://tools.ietf.org/html/draft-naderi-ipv6-probing recently.

   Brian

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

Re: [homenet] sorting out the right ipv6 addr to choose and name in a source specific world

[Brian E Carpenter]

On 18/12/2014 03:16, Dave Taht wrote:

...
 The ideal scenario is where the host app picks the best address for
 each connection type, and I am a little vague on what actually
 happens. What my backbrain (but not RFC 3484 - is there a later rfc
 for what gai.conf should do?) 

Not sure if anyone else has responded to that:

Yes, it was obsoleted by RFC6724. It probably won't change anything
material for this thread, but it's very important for other reasons.

btw I strongly recommend the pages like this one:
http://www.rfc-editor.org/info/rfc3484
if you want to get Obsoleted by/Updated by/Errata information
for any RFC.

   Brian

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

Re: [homenet] sorting out the right ipv6 addr to choose and name in a source specific world

[Brian E Carpenter]

On 19/12/2014 11:22, Juliusz Chroboczek wrote:
 Shouldn't we reduce the amount of cross-posting at some point?
 
 mptcp, I'm told, is likely to show up in Apple and Google products and
 infrastructure, and my idea (and many others) is that you don't always have
 to pick the perfect address for the SYN, just one that works, but rather one
 can add better addresses as one discovers them.
 
 But bad luck if you need UDP.
 
 Some form of intelligent probing does seem to be the answer,
 
 I'd like to attract your attention to the work that Matthieu Boutier has
 been doing on mosh, Keith Winstein's UDP-based ssh replacement:
 
   http://comments.gmane.org/gmane.network.mosh.devel/749
 
 Boutier's version of mosh builds connections across all source/destination
 pairs, and picks the one with lowest RTT.  

Sounds interesting. In the ideal world, that would be a pluggable
policy algorithm. Lowest RTT may not always be the best choice.
NAROS* suggested distributing policy from a single source, for
example.

The point about shim6, of course, is that allows you to change
horses in midstream without bothering the transport layer.
It's a real shame we don't know how to deploy it, especially
for homenets where nobody manages the routing policy.

   Brian

* C. Launois, O. Bonaventure, and M. Lobelle. The NAROS approach for IPv6
multihoming with traffic engineering. volume 2811 of Lecture Notes in
Computer
Science, pages 112–121. Springer Berlin Heidelberg, 2003.

 It's a work in progress --
 there are multiple versions, and Matthieu has yet to decide which
 implementation he's going to submit for inclusion in mainline mosh.
 
 We hope to write that stuff down when Matthieu has decided which is the
 right version, but I'm not promising any hard deadlines -- we have a lot
 of stuff that we want to write down.
 
 but certainly that needs to be generic because we cannot expect
 all apps developers to reinvent it.
 
 Uh-huh.  But there's only one thing that's worse than generalising from
 one example -- it's generalising from zero eexamples.
 
 http://tools.ietf.org/html/draft-naderi-ipv6-probing recently.
 
 I'll have a look, thanks for the pointer.
 
 -- Juliusz
 

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

Re: [homenet] sorting out the right ipv6 addr to choose and name in a source specific world

[Brian E Carpenter]

On 19/12/2014 13:47, joel jaeggli wrote:
 On 12/18/14 4:39 PM, Jim Gettys wrote:


 On Thu, Dec 18, 2014 at 7:19 PM, Brian E Carpenter
 brian.e.carpen...@gmail.com mailto:brian.e.carpen...@gmail.com wrote:

 On 19/12/2014 11:22, Juliusz Chroboczek wrote:
  Shouldn't we reduce the amount of cross-posting at some point?
 
  mptcp, I'm told, is likely to show up in Apple and Google
 products and
  infrastructure, and my idea (and many others) is that you
 don't always have
  to pick the perfect address for the SYN, just one that works,
 but rather one
  can add better addresses as one discovers them.
 
  But bad luck if you need UDP.
 
  Some form of intelligent probing does seem to be the answer,
 
  I'd like to attract your attention to the work that Matthieu
 Boutier has
  been doing on mosh, Keith Winstein's UDP-based ssh replacement:
 
http://comments.gmane.org/gmane.network.mosh.devel/749
 
  Boutier's version of mosh builds connections across all
 source/destination
  pairs, and picks the one with lowest RTT.

 Sounds interesting. In the ideal world, that would be a pluggable
 policy algorithm. Lowest RTT may not always be the best choice.
 NAROS* suggested distributing policy from a single source, for
 example.

 The point about shim6, of course, is that allows you to change
 horses in midstream without bothering the transport layer.
 It's a real shame we don't know how to deploy it, especially
 for homenets where nobody manages the routing policy.


 ​
 What were the problems with getting shim6 deployed? 

 need a time machine
 
 https://www.nanog.org/meetings/nanog35/presentations/schiller.pdf

Well, let's not start that argument again. Shim6 was never intended to
address operator's concerns, so it didn't. The real world problems are
these:

1. Most firewalls drop packets containing the shim6 extension header.

2. When shim6 switches addresses, the packets get a big bigger and
that might reveal a PMTUD problem.

3. Absent SADR in the exit router, shim6 has a high chance of falling
victim to BCP38 filtering.

More details:
H. Naderi  B.E. Carpenter, Putting SHIM6 into Practice,
Australasian Telecommunication Networks and Applications Conference
(ATNAC 2014),
Melbourne (November 2014).
https://www.cs.auckland.ac.nz/~brian/Shim6-ATNAC14-subm.pdf

Brian

 
 There appear to have been 
 ​a Linux implementation, and if the idea now has merit, that is enough
 of the market (which is very responsive) ​
 ​to get significant deployment, and to do so quickly. (codel/fq_codel
 went from concept to shipping code is under 3 months, with wide test
 deployment in a year, and now becoming default).  We aren't talking
 about 5 year product cycles any more.

 As to policy, the home routers themselves give us a place to enable
 people to state the policy they want (e.g. only use the LTE upstream
 if the cheap broadband service is unavailable...).
 - Jim


Brian

 * C. Launois, O. Bonaventure, and M. Lobelle. The NAROS approach
 for IPv6
 multihoming with traffic engineering. volume 2811 of Lecture Notes in
 Computer
 Science, pages 112–121. Springer Berlin Heidelberg, 2003.

  It's a work in progress --
  there are multiple versions, and Matthieu has yet to decide which
  implementation he's going to submit for inclusion in mainline mosh.
 
  We hope to write that stuff down when Matthieu has decided which
 is the
  right version, but I'm not promising any hard deadlines -- we
 have a lot
  of stuff that we want to write down.
 
  but certainly that needs to be generic because we cannot expect
  all apps developers to reinvent it.
 
  Uh-huh.  But there's only one thing that's worse than
 generalising from
  one example -- it's generalising from zero eexamples.
 
  http://tools.ietf.org/html/draft-naderi-ipv6-probing recently.
 
  I'll have a look, thanks for the pointer.
 
  -- Juliusz
 

 ___
 homenet mailing list
 homenet@ietf.org mailto: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] sorting out the right ipv6 addr to choose and name in a source specific world

[Brian E Carpenter]

On 19/12/2014 14:49, Juliusz Chroboczek wrote:
 Boutier's version of mosh builds connections across all source/destination
 pairs, and picks the one with lowest RTT.  
 
 Sounds interesting. In the ideal world, that would be a pluggable
 policy algorithm. Lowest RTT may not always be the best choice.
 
 It is, in our particular context.  That's the nice thing about working at
 the application layer -- you are the application, so you have a pretty
 good idea of what the desirable properties are.  Mosh is an interactive
 shell, and in this particular context it's latency you want to optimise
 for.

Are you sure? Suppose I open a file transfer window (which as a matter
of fact I do almost every time I use SSH these days). For large file
transfers
I might want to specify cheapest not fastest.

 Once we gain some real-world experience from mosh, we can think about
 making something more generic.  But I, at least, don't feel comfortable
 about doing that.

Understood. But all I'm thinking is that you might make that bit a
self-contained
module.

Brian

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

[homenet] Queries on draft-ietf-homenet-hncp-02

[Brian E Carpenter]

Hi,

I'm doing my homework (pun intended) by trying to thoroughly
understand HNCP. At the moment I have a few naive questions:

 3.  Data model
...
   A unique node identifier.  It may be a public key, unique hardware
   ID, or some other unique blob of binary data which HNCP can run a
   hash upon to obtain a node identifier that is very likely unique
   among the set of routers in the homenet.

This definition eats its own tail. It [is] binary data which HNCP can...
hash to obtain a node identifier...

If you are trying to distinguish a unique node identifier from a hashed
node identifier, I think you need to be very specific with terminology.
Actually I could not understand what this meant until I read this text:

 4.3.  HNCP Protocol Message Processing
...
If this happens more than 3 times in 60 seconds and the local node
identifier is not globally unique, there may be more than one router
with the same node identifier on the network.  If there is no global
guarantee of unique node identifier, a new node identifier SHOULD be
generated and node data republished accordingly.

I *assume* that at this point, 'node identifier' means 'hashed node
identifier' and that 'unique node identifier' means 'unique hashed
node identifier.' But it's not clear to me how the node in question
knows that 'the local node identifier is not globally unique.'

Of course I have anima eyes, and I think of node IDs as being
cryptographically bound to a key pair and registered with the
trust anchor. In that case, a node ID clash would be a very big
deal, and generating a new node ID would break all dependent
trust relationships.

It would probably be better if this aspect of HNCP was well
separated. At least, make the automatic regeneration of a
node ID a configurable option, since in a network with a trust
anchor and cryptographic IDs, this will be different.

'Link Identifier' is mentioned several times before it's defined.
Once, it is spelt 'Link-Identifier' which is a bit confusing when
searching.

Then it is defined:

   Link Identifier is the local HNCP identifier of the link the
   prefix is assigned to.

This sentence occurs twice, but it doesn't help me because the
phrase HNCP identifier isn't defined. All that has been defined
is 'node identifier' and that doesn't identify an interface, let
alone a link. (I raised a related question on draft-ietf-homenet-
prefix-assignment, and I'm still unclear how HNCP determines
that multiple interfaces of a node are connected to the same
link, which would presumably have the same Link Identifier
on different interfaces.)

Assuming I know what a Link Identifier is, the phrases Neighbor
Link Identifier and Local Link Identifier are also used
without definition. It isn't obvious to me where they come from.

That's it for now. I plan to read the draft again when I've
understood these points better.

Regards
   Brian




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

Re: [homenet] Follow-up on HNCP security / trust draft

[Brian E Carpenter]

Steven,

First, I'd like to repeat a comment I made about a month ago:

 So, what we *really* need is a full homenet threat analysis.

In other words I think there's a real risk of overlooking exposures
if we rely only on a threat analysis for HNCP itself.

More below:

On 20/11/2014 22:30, Steven Barth wrote:
 Hello Everyone,
 
 unfortunately the presentation of the security and trust draft was bit
 rushed in Hawaii.
 
 I intent to merge that draft with the main HNCP one if there are no
 blocking objections.

Certainly it's reasonable to include HNCP-specific security measures
in the HNCP protocol specification. However, I'm not yet convinced that
the mechanisms you describe really only apply to HNCP (see below).

 So if you have some time please review it so we can get any issues or
 unclarities out of the way soon.
 
 
 Here is a quick outline of the draft's contents:
 
 * Threats to homenet border determination (with focus on automatic
 algorithm)
 * Threats to HNCP payloads (multicast, unicast)
 * Ways to secure the unicast channel
 * 3 security models: PSK, PKI, Trust Consensus
 * Details about the Trust Consensus Mechanism
 * Means to bootstrap Trust Relationships

I have a feeling that these mechanisms need to apply more widely than
to HNCP transactions. If they are done well, they could be used for just
about anything. That remark could be transcribed directly into the anima
discussion, too, so we definitely need to coordinate here.

Brian

 * Dealing with additional (routing) protocols (lack of) security features
 
 
 Please see the slides for a short content summary.
 http://tools.ietf.org/agenda/91/slides/slides-91-homenet-6.pdf
 
 And the full draft for reference.
 http://tools.ietf.org/html/draft-barth-homenet-hncp-security-trust-01
 
 
 
 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

[homenet] draft-cheshire-homenet-dot-home-01

[Brian E Carpenter]

What's the mechanism for formal consultation with the DNS TLD
community on this? Just acknowledging comments from someone at
ICANN is not nearly enough.

   Brian

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

Re: [homenet] draft-cheshire-homenet-dot-home-01

[Brian E Carpenter]

On 13/11/2014 12:44, Ralph Droms wrote:
 On Nov 12, 2014, at 1:03 PM 11/12/14, Andrew Sullivan 
 a...@anvilwalrusden.com wrote:
 
 On Wed, Nov 12, 2014 at 11:31:56AM -1000, Ralph Droms wrote:
 Brian - I missed the discussion in homenet, so this reference may have 
 already been cited: RFC 6761

 That's the way we register the special use names.  What we don't have
 is a way, apart from sending a liaison statement, to tell ICANN what
 we're planning to do.
 
 Thanks - that's an important clarification.
 
 In this particular case, I think it would be extremely important to
 get positive affirmation that ICANN as an organization is in favour of
 registering these names for special use, because the names in question
 have in fact been applied for and applicants have spent not
 inconsiderable money on those applications.
 
 Agreed.

Violently agreed. There are definite feelings in ICANN-land that the IETF
didn't consult enough over RFC 6761, and adding a new TLD reserved for
technical purposes REQUIRES a careful liaison process (to establish that
it *is* a technical rather than a commercial or policy-based TLD name).

Given that there are currently 11 commercial applications* to delegate
the TLD home., I think the first step for the draft in question is
to choose a new name. It's close to the definition of insanity to
compete with the several million dollars already paid to ICANN.

* Search for home at
https://gtldresult.icann.org/application-result/applicationstatus/viewstatus

Brian

 
 - Ralph
 
 
  I'm not convinced that it
 would be safe for the IETF to make such a special-use registration at
 this point without an explicit declaration from ICANN not only that
 they wanted not to delegate for an indeterminate period of time, but
 that they would like the special-use registration as well.

 Best regards,

 A

 -- 
 Andrew Sullivan
 a...@anvilwalrusden.com

 ___
 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-prefix-assignment-01.txt

[Brian E Carpenter]

Hi,

A few somewhat random comments:

Everywhere you refer to small and smaller prefixes.
This is confusing. I assume you mean long and longer.

 4.1.  Data structures
...
Router ID:  The identifier of the advertising router.

Who assigns this? I think you mention that later but here
it's just a dangling reference.

 
Link ID:  If the assignment is made on a connected link, an interface
  identifier of the interface connected to that link.

That's a bit confusing because a link is not an interface, and the same
link connected to multiple interfaces will have multiple Link IDs
by this definition. Also, you can't call it Interface ID because that
has a specific meaning in IPv6. I don't have a good suggestion but
it needs to be tidied up IMHO.

 4.2.  Routers' Interfaces
 
Each interface MUST either be considered as internal or external.
Prefixes and addresses are only assigned to internal interfaces.  The
criteria to make this distinction are out of the scope of this
document.

By criteria do you mean mechanisms? That seems to be a discovery
problem (and it also occurs during security bootstrapping). But
I think you really need to define what internal and external *means*.
The words are not self-defining.

If an internal interface becomes external, all prefixes and addresses
assigned on the considered interface MUST be deleted...

Yes but... they can't be dropped instantly; at least for v6 they have
to go through the deprecation phase, surely?

...
Whenever two or more interfaces are connected to the same link,

How is this known to be the case? I imagine a little TV camera
peeping out from the router to look at the cables...

 4.5.  Designated Router
 
On a link where custom host configuration must be provided, or
whenever SLAAC cannot be used, a DHCP server must be elected.  That
router is called designated router and is dynamically chosen by the
prefix assignment algorithm.

You are assuming without stating it that the DHCP server MUST be located
in the same device as a router. Why?

Is the designated router the same one for v4 and v6, and if so, why?

 4.5.1.  Sending Router Advertisement
 
...
The designated router MUST advertise itself as a router for all IPv6
delegated prefixes using Route Information Options [RFC4191],
independently of whether there is a default route or not.

Why? Maybe different MIF PVDs should be handled by different routers,
if some form of SADR is supported.

 6.6.  Making a New Assignment
...
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, the use of 64 bits long prefixes
is RECOMMENDED (See [I-D.ietf-6man-why64]).

And for v4?

 6.10.  Downstream DHCPv6 Prefix Delegation support
...

 If DHCPv6 Reconfigure is
not supported, leases lifetimes SHOULD be significantly small.

Can't parse significantly. Can you quantify this?

 9.1.1.  Choosing the ULA prefix
 
When a stable ULA prefix is advertised, all routers SHOULD remember
that prefix alongwith its associated valid and preferred lifetime.
If this prefix stops being advertised (e.g. due to a network split)
while its preferred lifetime is not null, the same ULA prefix SHOULD
be selected using the same valid and preferred lifetimes.

What is doing the selecting? This is a case where the passive tense is
confusing.

 9.1.2.  Advertising a ULA prefix
 
A router MAY start advertising a ULA prefix whenever the two
following conditions are met:
 
o  It is the network leader.
 
o  There is no other advertised ULA prefix.
 
If no IPv6 prefix is available at all, the network leader SHOULD
start advertising a ULA delegated prefix.

Do these two bullets refer to the same thing (a complete ULA /48) or
to longer ULA prefixes?

 
Additionaly, a router SHOULD start advertising its own ULA prefix
whenever the three following conditions are met:
 
o  A stable ULA prefix is advertised by another router.
 
o  The router owns the advertised stable ULA prefix.

I got confused about which router is which. Could you give
them names, e.g.

Additionaly, a router A SHOULD start advertising its own ULA prefix
whenever the three following conditions are met:

o  A stable ULA prefix is advertised by another router B.

o  The router A owns the advertised stable ULA prefix.

And then it still doesn't make sense to me (and again I'm asking
whether we are talking about a /48 or something longer).

A router MUST stop advertising a spontaenously generated ULA prefix
whenever one of the two following condition is met:
 
o  A different ULA prefix is being advertised.
 
o  The same prefix is advertised by another router, and the router
   doesn't own that prefix.

Here too I am confused about which router is which and which prefix

Re: [homenet] [Anima] ANIMA scope + homenet interaction + charter v15

[Brian E Carpenter]

Right. Also of course we should follow the correct architectural
principle (that any prefix length is valid) but also the agreed
practical position (that the subnet length is normally /64,
as discussed in draft-ietf-6man-why64 that was just approved).

Brian


On 02/11/2014 02:25, Sheng Jiang wrote:
 Hi, Ted,
 
 Yes, we mixed different concepts. Actually, this was a very good discussion. 
 It gives a very good hints to improve the autonomic prefix management draft. 
 Now, we know prefix management should be at least categoried into prefix 
 assignment and prefix distribution. :) Thanks for your participation in this 
 discussion.
 
 Best regards,
 
 Sheng
 
 From: homenet [homenet-boun...@ietf.org] on behalf of Ted Lemon 
 [mel...@fugue.com]
 Sent: 01 November 2014 20:31
 To: Sheng Jiang
 Cc: Benoit Claise; homenet@ietf.org; Markus Stenberg; an...@ietf.org
 Subject: Re: [homenet] [Anima] ANIMA scope + homenet interaction + charter
   v15
 
 On Nov 1, 2014, at 7:41 AM, Sheng Jiang jiangsh...@huawei.com wrote:
 But getting back to where we start the discussion, I still think in a large 
 network, the requesting prefix may not always be /64. It is reasonable to 
 have multiple distributed sources for prefix assignment, in a large network. 
 Autonomic network use case also includes to manage the prefix resource among 
 these prefix pools.
 
 It's certainly true that if you have multiple repositories for prefixes to 
 assign, those repositories will need to transfer more than one /64 at a time, 
 and it will be desirable to maintain pools of prefixes on these repositories 
 that are aggregated into larger prefixes.   But prefix _assignment_ will 
 always be a single /64.   I suspect that this is the core of our 
 miscommunication--if you talk about prefix assignment and prefix distribution 
 as if they are the same thing, which is what we started out doing, then it's 
 easy to imagine that we are talking about the same thing when really one of 
 is talking about assignment (me) and the other about distribution (you).  
 Sorry about that.
 
 ___
 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] [Anima] ANIMA scope + homenet interaction + charter v15

[Brian E Carpenter]

On 01/11/2014 04:47, Ted Lemon wrote:
 On Oct 31, 2014, at 10:55 AM, Sheng Jiang jiangsh...@huawei.com wrote:
 The current general mechanism are too general to work for the use case of 
 hierarchical prefix delegation. But if we add hierarchical topology and no 
 bypass requests as constraint conditions, we may be able to make 
 hierarchical prefix delegation work.
 
 No, that is not the point I am making.   The point I am making is that 
 hierarchical delegation simply won't work, no matter what mechanism you put 
 in place to do it, because the network has to be able to grow incrementally.  
  With that as a base assumption, you cannot predict where the network will 
 grow, so you don't know how to construct the hierarchy.   Once the hierarchy 
 is constructed, you would have to renumber on a regular basis to make 
 hierarchical delegation work.   I think it is preferable to simply allow for 
 a complete routing table, and then try as best as possible to make routing 
 hierarchical, without demanding perfection.

Well yes. That's exactly why in autonomic management of prefixes,
we need peer to peer negotiation, as in I need 3 /64s that I
don't have, do you have any spare ones for me? Maybe it's
badly explained but that is the whole point of our use case.

   Brian

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