Re: [homenet] naming drafts

[Ray Hunter (v6ops)]

Stephen Farrell wrote on 07/06/2021 21:32:


Hi Michael,

On 05/06/2021 19:46, Michael Richardson wrote:

Well, I'd be happy to discuss with this them again, but they'd have to
actually tell us what "DDNS" really is for them.


Just to clarify: I don't think/claim DDNS is "better" than
the proposal here, rather I don't find the arguments as to
why this is "better" convincing, and so, given that DDNS is
deployed, and has some similarity, I'm wondering if this
spec really has much of a chance at gaining traction.

As a result, I don't really think there's that much value
in attempting a point-scoring exercise comparing the two,
the question for me is really whether or not this spec is
so much better than DDNS that it could displace DDNS, and
I'm not convinced as of now. (But I'm often wrong of course.)

Cheers,
S.


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


Just trying to understand this hurdle/ line of reasoning.

So in addition to achieving "rough consensus", the IETF standardization 
process must also produce drafts that are very likely to gain traction 
to displace non-IETF non-standardised products that are already widely 
commercially deployed?


If that is the case, then perhaps the WG should have steered the draft 
to have been "DDNS, but standardised" or "a TR-069 compatible interface 
for DNS zone delegation".


--
regards,
RayH

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

Re: [homenet] [dhcwg] WGLC started -- draft-ietf-homenet-naming-architecture-dhc-options-12

[Ray Hunter (v6ops)]

Hi Ted, thanks for the comment.

I agree.

Plus one more point.

The ISP hosts the reverse zone.
The ISP also controls any reverse zone to customer assignments, and is 
in control of any renumbering.
The ISP may therefore choose to simply wipe any reverse zone content 
after renumbering occurs.

That would mitigate any re-use or privacy concerns.

Otherwise the HNA may no longer have authority over the content after a 
flash renumbering (e.g. if the ISP is simply authenticating customers 
based on source address of the updates)


regards,

Ted Lemon wrote on 05/05/2021 18:42:
On May 5, 2021, at 11:44 AM, Michael Richardson > wrote:

The end user might suffer slightly by having locally served
reverse names that are no longer connected: they should obsolete that 
zone

when they realize that their PD hasn't been renewed, until such time,
(if it was a flash renumber), they would be right to think that they
legitimately control them.


In practice I don’t think this is an issue. The reverse lookup is 
usually triggered by receipt of a message from an IP address, so as 
long as the IP address is still in use internally, the presence of the 
reverse zone is wanted. When the address changes, the old zone becomes 
obsolete whether it continues to be served or not. The likelihood of 
the zone being re-allocated to some other network for which the 
original network will then do a reverse lookup is very small, so I 
don’t think there’s any reason to be concerned about this.




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


--
regards,
RayH

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

Re: [homenet] draft-ietf-homenet-naming-architecture-dhc-options-08

[Ray Hunter (v6ops)]

Hi Daniel,

I have a question both for this draft and our "own" Homenet draft

Up until now we've been passing the specification of the DM * Reverse DM 
connections via separate configuration parameters: address/name, port 
number, and transport protocol.


Should we instead be using a DNS URI from 
https://tools.ietf.org/html/rfc4501?


That reduces the DM spec to a single parameter that is also extensible 
for the future.


regards,

Daniel Migault wrote on 01/04/2021 18:18:

Hi Bernie,

I apology for missing that email. Your comments addressed an old 
version, however most of them applies to the new version.  I think all 
comments have been addressed on my working local copy and I provide 
more details on how we addressed them.


I do have one remaining question regarding the IANA section on whether 
the specific values associated to a field of the DHCP option are part 
of the IANA section with the creation of a new registry or not.


Please see inline my response for more details.


Thanks for the review!

Yours,
Daniel

*From:* Bernie Volz (volz) 
*Sent:* Tuesday, March 9, 2021 11:54 AM
*To:* draft-ietf-homenet-naming-architecture-dhc-opti...@ietf.org 


*Subject:* draft-ietf-homenet-naming-architecture-dhc-options-08

Hi:

Took a quick look at the document … just a few nits to point out:

 1. You use “Homnet” in 2 places; I think that should be Homenet?


fixed thanks.


 2. For the FQDN option data, please make sure you refer to encoding
used is specified in https://tools.ietf.org/html/rfc8415#section-10

< mglt>
thanks, the encoding has been specified for all FQDN data, i.e., the 
Registered Domain, the Distribusion Master and Reverse Distribution 
Master.



 3. In 4.1, the diagram shows “Public Key Data” yet the definition
below it has “Client Public Key Data”; fix them to match.


This has been fixed in the previous version by removing these options.


 4. Sometimes you indicate the “length” of the data in the options,
sometimes you don’t; and “(varaiable)” is used in one place which
is misspelled.


Variable has been fixed. I suppose the these comments has been fixed 
from the latest version. As far as i can see, the current version has 
(variable) indicated for all variable fields. and option-len field in 
each description.




 5. You still reference RFC3315 when current DHCPv6 standard is RFC8415.


I have updated the reference. Thanks.


 6. The IANA considerations needs some work. You might see

https://datatracker.ietf.org/doc/draft-ietf-dots-server-discovery/15/?include_text=1
as an example of a recent very good IANA considerations section.


I have updated the IANA section. I do have one remaining question.
One option specifies the the values of a field in a DHCP option. I am 
wondering if a specific registry needs to be created or not. For now I 
have assumed yes. The IANA section looks like:


IANA is requested to assign the following new DHCPv6 Option Codes in 
the registry maintained in: 
https://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml#dhcpv6-parameters-2. 



~~~
Value Description                   Client ORO     Singleton Option
TBD1  OPTION_REGISTERED_DOMAIN      Yes            Yes
TBD2  OPTION_DIST_MASTER            Yes            Yes
TBD3  OPTION_REVERSE_DIST_MASTER    Yes            Yes
~~~

The document also requests a Supported Transport Registry:

~~~
Bit | Transport Protocol | Reference
++---
 0  | DNS over TLS       |
 1  | DNS over HTTPS     |
2-7 | unallocated        |
~~~



  * Bernie



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


--
regards,
RayH

___
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-08.txt

[Ray Hunter (v6ops)]

Hi Daniel,

Thanks for publishing this draft.

I have a three comments/concerns.

Firstly: "this option is also defined in [I-D.ietf-dhc-sedhcpv6]."

I just want to clarify that you are going to provide a new option code, 
but with the identical semantics.


I do think you need a separate code to avoid parsing ambiguity.

But also going forward if the specification is amended, then this would 
also be amended for this usage.


i.e. s/DNSKEY RDATA format as defined in [RFC4034]/DNSKEY RDATA format 
as defined in [RFC4034] or as amended/ ?


Second: I was planning on using certificates to secure the control 
channel. The certificate would be linked to the individual HNA.


Is there any provision for either downloading the relevant certificate 
given the key data, or for containing the certificate directly in the 
DHCP option?


Thirdly: I know some operators have concerns about "individualising" 
DHCP responses per user, rather than a static "get you configuration 
here" type bootstrap for all users.


Has this concern been discussed with any ISP's and is there an 
alternative method of individualizing the bootstrap process?


regards,

Daniel Migault wrote on 22/10/2020 15:10:

Hi,

Please find here an update for the DHCP options aiming at configuring 
the Home Naming Authority (HNA). The document has been updated to 
better reflect the changes made on the front-end draft. As the 
front-end draft enables the Distributed Master (DM) and the HNA to 
agree on some configuration parameters, these parameters no longer 
need to be provided via DHCP. As a result, this resulted in 
simplifying the DHCP options which is reflected by the current version.


As always, comments are welcome!

Yours,
Daniel




-- Forwarded message -
From: mailto:internet-dra...@ietf.org>>
Date: Thu, Oct 22, 2020 at 9:04 AM
Subject: [homenet] I-D Action: 
draft-ietf-homenet-naming-architecture-dhc-options-08.txt

To: mailto:i-d-annou...@ietf.org>>
Cc: mailto:homenet@ietf.org>>



A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

This draft is a work item of the Home Networking WG of the IETF.

        Title           : DHCPv6 Options for Home Network Naming Authority
        Authors         : Daniel Migault
                          Ralf Weber
                          Tomek Mrugalski
                          Chris Griffiths
                          Wouter Cloetens
        Filename        : 
draft-ietf-homenet-naming-architecture-dhc-options-08.txt

        Pages           : 14
        Date            : 2020-10-22

Abstract:
   This document defines DHCPv6 options so any agnostic Homnet Naming
   Authority (HNA) can automatically proceed to the appropriate
   configuration and outsource the authoritative naming service for the
   home network.  In most cases, the outsourcing mechanism is
   transparent for the end user.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-homenet-naming-architecture-dhc-options/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-homenet-naming-architecture-dhc-options-08
https://datatracker.ietf.org/doc/html/draft-ietf-homenet-naming-architecture-dhc-options-08

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-homenet-naming-architecture-dhc-options-08


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


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


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


--
Daniel Migault
Ericsson


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


--
regards,
RayH

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

Re: [homenet] biggest L2 domain

[Ray Hunter (v6ops)]

Gert Doering wrote on 13/12/2019 18:26:

Hi,

On Fri, Dec 13, 2019 at 09:54:08AM -0500, Michael Richardson wrote:

I thought that we wrote somewhere in RFC7368 that the Homenet router should
collect as many ports as possible together into a single L2 zone.
I can't find that text right now. Did it go away?

In testing, we have found a device that does not put it's 5-"LAN" ports into
a bridge.  That's probably a missing configuration, but in the meantime, we
have an interesting HNCP and naming setup!

My understanding of "homenet" and "HNCP" devices has always been "every
single hole in the box is a routed port".  Now that's my understanding and
not necessarily written down somewhere.

Magically grouping ports into a common L2 network and then un-grouping
them in case one of them turns out to have another HNCP device connected
sounds like an interesting challenge, to say the least :-)

Gert Doering
 -- NetMaster


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

Hi,

I agree that learning L2 topology is not trivial and is not covered in 
the current Homenet daemon.


Learning at boot time or port status change would require stopping 
forwarding to avoid loops, which is undesirable in networks where 
devices are plugged and unplugged (think wired laptop moving around 
interrupting media streaming on another device)


I was thinking of something like bringing up all ports in L3 at boot 
time, on a dedicated VLAN, see what's there, and then "annealing" the 
network later.


So if two (or more) ports are detected as only having hosts, they could 
later be merged to be one L2 domain after some period of stable operations.


One name and prefix would be primary, whilst the others would be 
configured initially but gradually removed (as leases die), which would 
be the equivalent of a phased

renumbering event with a flag day.

But other alternative of treating all ports as L3 ports forever would 
seem to require hierarchy in the naming solutions (which doesn't exist 
today).


--
regards,
RayH

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

Re: [homenet] outsourcing architecture [meeting notes]

[Ray Hunter (v6ops)]

Hi Daniel,

Here's my input where there wasn't time to provide at the mic in the 
meeting.


Daniel Migault wrote on 19/11/2019 10:36:

Hi,

So my notes/comments regarding the feedbacks received are:
* mentioning the work on axfr over tls

No problem with referencing this and it's helpful feedback.

I currently only protect the HNA based on a simple IP ACL in knot (allow 
DM for AXFR), which is effective, and doesn't eat resources on the HNA.


IMHO We almost certainly already have the required credentials in place 
for mutual authentication of the synchronisation channel (from the 
control channel) and I presume there's no issue with re-using these 
credentials in the reverse direction for the TLS session from DM -> HNA.


In my implementation, the HNA could authenticate itself to the DM by 
using the same certificate signing request signed by a private 
certificate from the DM that was already provided out of band, based on 
a trust anchor at the DM using it's own self-signed root certificate. 
There's no need for any additional public certificate.


The DM could authenticate itself to the HNA using a public Let's Encrypt 
certificate with subject common name matching the DM, with a trust 
anchor of the standard baked in root certs. The name of the DM is 
already provided out of band for initiating the control channel.



* cds needs to be placed in the homenet zone by the HNA
We already foresaw using CDS for ongoing maintenance of the DS key 
[RFC7344 + RFC8078].


See Section 5.2 of our draft.

/Though the HNA may also later directly update the values of the DS via 
the Control Channel, it is RECOMMENDED to use other mechanisms such as 
CDS and CDNSKEY [RFC7344] are used for key roll overs./


So I have no problem with the DM updating the DS key based on CDS 
(Section 4) during normal operations.


However, this can't be the ONLY method of maintaining the DS (which I 
believe was the question asked at the mic).


Because we're bootstrapping the trust between the HNA and the DM, and 
there's little or no previous knowledge of the other party, we need 
additional checks and balances. The KSK may also be lost.


That's why in my implementation we can always create, update, and delete 
the DS directly via the control channel.


The TLS transport on the control channel provides the authenticated 
channel referred to in Section 3.1. of 8078.


The control channel includes mutual authentication using certificates in 
my implementation (we know who we're talking to = authenticated).


I also check if this particular HNA is authourised to update this 
particular DS RR.


/When an UPDATE is received by the DM on the control channel, the 
message SHOULD be checked for authenticity (e.g. the source zone in the 
update message corresponds to the common name of the certificate used by 
the HNA), and then the DM SHOULD use the received information to 
configure the synchronization channel./


That was covered in some text I submitted on the github, but it isn't 
included in the published version 9. I missed that. We should go through 
and make sure those additional checks on the control channel, and why 
they're needed, are correctly documented.


The other options suggested in RFC8078 are inadequate or technically 
difficult IMHO.


RFC8078 Section 3.2 Extra check is technically hard IMHO

What would we check?

RFC8078 Section 3.3. Accepting after delay is inadequate.

We're talking public internet here. Otherwise there could be a resource 
exhaustion attack on the DM by an attacker inserting random DS RR's, or 
denial of service attacks by timing updates on unsuspecting HNA's that 
haven't renewed their DS for a while, or cant defend it quickly enough 
if they're offline.


RFC8078 Section 3.4 Accepting with Challenge

Possible, but then we'd have to define a (new) challenge response protocol.

ACME only works once DNS delegation is established, so you have a 
chicken-egg problem.


RFC8078 Section 3.5 Accepting from Inception
See comments on RFC8078 Section 3.3

* considering factory reset and removal of the provisioned keys ? - we 
need to think of this scenario.

Already covered in my implementation.

The KSK keys for the zone are generated on the HNA itself, and are never 
ever transmitted or stored outside the HNA, so if they're lost (either 
by factory reset or hardware replacement) there needs to be a recovery 
mechanism that does not depend on any state stored on the DM or HNA.


As long as an HNA still has a copy of the certificate signed by the DM, 
or they can grab a new certificate from the DM supplier (out of band), 
they can either update, delete, or replace the existing DS RR without 
knowing the old/lost KSK.


That was one reason for using Section 3.1 of 8078 for authenticating the 
creation, update, and deletion of DS RR's via the control channel.


* securing the synchronization between primary/secondary with TLS ? 
Feed backs are still unclear to me whether 1) we need to secure this 
channel. 

Re: [homenet] https://tools.ietf.org/id/draft-ietf-mboned-ieee802-mcast-problems-09.txt

[Ray Hunter (v6ops)]

Dave Taht wrote on 23/10/2019 08:56:

has anyone here had much chance to review this?


Thanks for the prompt.

From a pure Homenet perspective, it reinforces that L3 routing is the 
correct solution for segmenting networks where end nodes have different 
characteristics. e.g. battery powered or different underlying LAN 
technology. And maybe we need a firewall in front of those segments to 
prevent inbound scanning traffic overloading the link.


Other than that I'm not sure it says much more than "Multicast is great 
for efficiency, until it isn't".


Section 3.2.4:
> On a wired network, there is not a huge difference between unicast, 
multicast and broadcast traffic.


I'd dispute this statement as being overly generic. Anyway, it doesn't 
add much to the discussion (about wireless).


The majority of modern wired Ethernets are actually effectively point to 
point networks, with multicast and broadcast being emulated in silicon 
or software.


Although maybe having a less visible impact than on wireless, multicast 
and broadcast can also have some similar operational impact on wired 
networks (waking nodes unnecessarily, switching via a slow (software) 
path in the main processor,  https://tools.ietf.org/html/rfc6583 etc.).


--
regards,
RayH

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

Re: [homenet] DNCP/HNCP Revisited

[Ray Hunter (v6ops)]

Juliusz Chroboczek wrote on 20/09/2019 14:23:

1) DNCP allows an option of whether a network state TLV contains optional
nested payload (HNCP) TLV's or not.

I'm pretty sure that's not the case.  RFC 7787 Section 7.2.2.

A OK so you're saying this is already covered in (Section 4.4 of) 7787

[...]


   state hash.  The Node State TLVs SHOULD NOT contain the optional
   node data part to avoid redundant transmission of node data,
   unless explicitly specified in the DNCP profile.
So what I was suggesting was merely additional clarification of that.

Careful here.  There is no optional part in the *network*-state TLV - this
TLV's payload is just the network state hash.  The optional payload is for
the *node*-state TLVs.

I see now.

The network state TLV's and node state TLV's are completely separate 
TLV's (not nested in any way) that can be both generated as the result 
of one inbound request (request network state TLV), and they may be sent 
in separate UDP packets.

The replying node MUST reply to all node state queries.  However, it is up
to the replying node whether these replies are sent in a single packet or
split into multiple packets.

So requesting multiple node status TLV's in one packet could lead to an
oversized UDP reply packet.

Yes, this was discussed back in July 2015.  Here's what I said back then:

 It should also say that a node MUST NOT send a datagram with a larger
 payload, and that it MUST silently drop any larger datagrams (optionally
 log to system management, etc.).  If this is not done, persistent state
 desynchronisation may occur.

This is what Markus replied:

 I am not sure I want to cripple use in non-crippled networks, just provide
 guaranteed base value which works everywhere and *RED ALERT* light should
 light up on crippledbox if it encounters this

Since nobody supported my position at the time, I had to agree to the
following:

   - Section 3 of RFC 778 says that "Each node MUST be able to receive (and
 potentially reassemble) UDP datagrams with a payload of at least
 4000 bytes."

   - there is no limit on the size of the packets that a node may send.


So if I understand you correctly, you're saying this is the problem of the
sender of the response to ensure UDP fragmentation doesn't break,

I'm not sure what you mean.  We certainly assume that the network obeys
RFCs 2460 and 4443.


and that multiple long UDP replies can be generated from a single query
packet (potential amplification).

Let's please discuss security at some other time, I'd like the current
discussion to come to a conclusion first.


If there's multiple UDP replies required for a single query, would you expect
sending of these individual packets to also be rate limited by trickle?

Let's please discuss congestion control at some other time, I'd like the
current discussion to come to a conclusion first.


What behavior would we expect from the requester during this time?

The requester parses each top-level TLV in turn, and acts upon it.

This is very illuminating for me, and removes a false assumption on my part.

Wait for all outstanding replies to arrive?

No.  The requester parses each top-level TLV and acts upon it as soon as
it arrives.


Re-transmit a node TLV request for missing / dropped replies?

How would the receiving node detect missing replies?

If some node-state TLVs are missing, then the receiving node's state might
not get updated correctly, which will cause the network hash to mismatch,
which will be detected when it receives a new network-state TLV
(trickle-driven, worst-case 17s).

-- Juliusz

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


Thanks very much for your patience and replies to my questions that have 
certainly filled gaps in my understanding of the protocol that I had 
from reading the standards and the code alone.


AFAICS there's certainly enough room for me to experiment with patches to
i) reduce MTU to avoid problems arising from L2 MTU mismatches and
ii) to reduce the amount of fragments (at the expense of more UDP packets)
without any tweaking of the standards.

My reason for investigating ii) is to potentially reduce the impact of 
the loss of an individual frame on a lossy link (we would lose 1 node 
status TLV from 1 device rather than multiple TLV's related to multiple 
devices).


--
regards,
RayH

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

Re: [homenet] DNCP/HNCP Revisited

[Ray Hunter (v6ops)]

Thanks for your response.

Juliusz Chroboczek wrote on 20/09/2019 12:40:

1) DNCP allows an option of whether a network state TLV contains optional
nested payload (HNCP) TLV's or not.

I'm pretty sure that's not the case.  RFC 7787 Section 7.2.2.

The Network-State TLV only contains the network state hash, short
Node-State TLVs are separate top-level TLVs.  An implementation may choose
to send them in the same packet, but they're independent TLVs and can be
sent in different packets.

A OK so you're saying this is already covered in (Section 4.4 of) 7787

  Upon receipt of:

   o  Request Network State TLV (Section 7.1.1 
): The receiver MUST reply
  with a Network State TLV (Section 7.2.2 
) and a Node State TLV
  (Section 7.2.3 ) for 
each node data used to calculate the network
  state hash.  The Node State TLVs SHOULD NOT contain the optional
  node data part to avoid redundant transmission of node data,
  unless explicitly specified in the DNCP profile.

So what I was suggesting was merely additional clarification of that.




2) The node requesting a node status TLV doesn't know in advance how big a
reply packet will be generated.
DNCP states that nodes MUST reply to all node status TLV queries.

The replying node MUST reply to all node state queries.  However, it is up
to the replying node whether these replies are sent in a single packet or
split into multiple packets.

In other words, the only constraint is that every single node state TLV
must be sent in its entirety within a single packet.  As described in
a previous mail, this does bound the amount of data that a single node can
publish, but no bounds on the total size of the network.


So requesting multiple node status TLV's in one packet could lead to an
oversized UDP reply packet.

The replying node's behaviour has nothing to do with whether the requests
are aggregated in a single packet or not.  The replying node processes
each request independently, whether it finds them in a single packet or in
multiple packets.

-- Juliusz

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


So if I understand you correctly, you're saying this is the problem of 
the sender of the response to ensure UDP fragmentation doesn't break, 
and that multiple long UDP replies can be generated from a single query 
packet (potential amplification).


If there's multiple UDP replies required for a single query, would you 
expect sending of these individual packets to also be rate limited by 
trickle?


What behavior would we expect from the requester during this time?
Wait for all outstanding replies to arrive?
Re-transmit a node TLV request for missing / dropped replies?

Thanks!

--
regards,
RayH

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

Re: [homenet] DNCP/HNCP Revisited

[Ray Hunter (v6ops)]

Juliusz Chroboczek wrote on 19/09/2019 01:02:

The problem is, how’d the packet get so big that it was fragmented?

HNCP relies on network-layer fragmentation: it uses UDP and has no
application-layer mechanism for fragmenting large TLVs.  See Section 4.2
and Appendix B.2 of RFC 7787.

Agreed. I'm aware it was a design decision.


(I seem to recall that an earlier version of DNCP included provisions for
application-layer fragmentation of TLVs, but that was removed at some
point.  I don't remember why.)
Yes. I've read earlier versions of the draft and it was an open point 
whether to do L7 fragmentation as part of HNCP or not.


I can't recall the exact discussion on list but it changed between 
version 4 and 5

https://tools.ietf.org/html/draft-ietf-homenet-hncp-04 (Appendix A)
https://tools.ietf.org/html/draft-ietf-homenet-hncp-05 (rely on UDP 
fragmentation)



Let's please come back to my question.  RFC 4443 paragraph 3.2 says

A Packet Too Big MUST be sent by a router in response to a packet
that it cannot forward because the packet is larger than the MTU of
the outgoing link.

If your tunnelling software violates this, how is it not buggy?

-- Juliusz

Yes, this is a very poor network set up that could be avoided.

Question is: is it worth addressing?

I'm still working on the basis of a simple workaround to address the L2 MTU 
mismatch (limit IPv6 UDP fragment size to 1280 octets).


The separate problem is that if the amount of HNCP state increases (e.g. due to 
electing a central name server or mud server or whatever), the apparent limit 
of having to transmit the entire superset of all node TLV states in a single 
UDP packet may become problematic.

I notice in the current Openwrt code that the max UDP packet size is set at 
9000 octets with the comment:

/* Very arbitrary. On some implementations, I have seen some issues
 * with 10+kb frames so we use this for now. It MUST be significantly
 * more than 4k, due to how code is written at the moment. */
#define HNCP_MAXIMUM_UNICAST_SIZE 9000

With current code (without expanding the TLV data set), and my sample test 
routers, that sets a current maximum network size of approx. 12 nodes.

--
regards,
RayH

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

Re: [homenet] DNCP/HNCP Revisited

[Ray Hunter (v6ops)]

Mark Andrews wrote on 18/09/2019 12:00:



Question: As a simple mitigation, is there any way of manually signalling to 
the kernel that ALL UDP packets on port 8231 should assume an PMTU of 1280 
octets?

setsockopt(IPV6_USE_MIN_MTU=1); from RFC 3542 works provided the OS has 
implemented it.  It’s a really pity that POSIX hasn’t picked up RFC 3542 in the 
16 years since it was published like they picked up RFC 3493.  This is a epic 
fail of SDOs.


Thanks for the tip.

Unfortunately checking  in the current openwrt build tree.
..
#if 0   /* not yet */
#define IPV6_USE_MIN_MTU    63
#endif

:( not yet implemented

--
regards,
RayH

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

[homenet] DNCP/HNCP Revisited

[Ray Hunter (v6ops)]

Hi,

I've been experimenting with Homenet before looking at enhancing HNCP 
for extended naming functionality (the current implementation only 
covers resolver configuration and not name server configuration).


During my testing I managed to break HNCP, so that it got stuck in a 
state where it didn't converge.


Looking at the specification in detail this shouldn't have been a 
surprise to me or anyone else due to the design choices that were made.




First observation: Running HNCP over L2TPv3 breaks HCNP because L2TPv3 
breaks UDP fragmentation (works as designed).


The L2TPv3 tunnel has a lower MTU than the local LAN, and does not 
report ICMP PTB, so HNCP packets in one direction get through, but 
replies get dropped.


Early drafts of HNCP stated that UDP fragmentation would not be broken 
in the Homenet for the foreseeable future. Well I managed to break that ;)


So this is a known situation.

Changing the MTU on the LAN interfaces of my routers to 1280 brought 
everything back to normal, as expected.


Question: If Homenets are moving to flat L2 meshes over foo, as some 
have said, will this impact HNCP?


The Linux kernel (in Openwrt) can/could easily support PMTUD.

But since the L2 tunnels don't report drops, it makes PMTUD potentially 
challenging for a simple protocol like HNCP.


Question: As a simple mitigation, is there any way of manually 
signalling to the kernel that ALL UDP packets on port 8231 should assume 
an PMTU of 1280 octets?


That wouldn't require any specification change and would allow HNCP to 
work reliably in the presence of tunnels and varying MTU's that don't 
match the local interface MTU.





Second Observation: HNCP packets grow quickly in size, which may become 
a concern for scaling.


Again, by design, DNCP is limited to TLV content of 64K (RFC7787 intro).

AFAICS that is 64K per DNCP system, not per node.

Question: Is that correct?

For my 4 node Homenet, HNCP reached 3140 octets, without any 
modifications or additions or long names.


Question: Does the amount of state scale linearly with the number of 
routers?


Question: Is this starting to become a concern?

The limitation for 64K seems to come from the following:

RFC7788
Request Network State TLV (Section 7.1.1): The receiver MUST reply
  with a Network State TLV (Section 7.2.2) and a Node State TLV
  (Section 7.2.3) for each node data used to calculate the network
  state hash.


In the Openwrt implementation, I observe that the requester is 
requesting the node state for all 4 devices in one packet.


I also observe that the reply from the peer contains the entire state of 
the entire Homenet in a single UDP packet (network TLV and node state 
TLV for all 4 routers + optional payload data).


Question: Is that as designed/intended? Is this where the 64K data limit 
comes from in RFC7787?


If this was a design goal to reduce chatiness, and improve convergence 
time, is it possible to implement this differently to reduce packet size 
and/or increase overall TLV data capacity?


Could the requester in step1 request the network status TLV, and the 
peer reply with just the network status TLV and the node TLV's, but 
without the underlying optional HNCP payload data TLV's.


Maybe include a new "more-HNCP-data-to-come" TLV to distinguish this 
from blank node data?


That would give enough information for both nodes to know exactly which 
payload data needed synchronising.


Then as step 2, the requester could individually request the Node TLV 
for each node one per packet, and the peer would reply with the Node TLV 
but this time including the optional data TLV's.


The receiver and peer would both know that HNCP hadn't converged whilst 
waiting for the additional data, and could mark it internally as being 
stale whilst waiting for the additional detailed update.


Question: What would break?

Question: What would need to be amended in the standard RFC? The 
more-HNCP-data-to-come TLV in RFC7788?


Question: Would this tweak increase the ±64K limit of TLV data from 
being per network to being 64K per node? [max UDP packet size for a 
single node TLV + associated payload data]


Question: Is this raw fragmentation by separating DNCP essentials from 
HNCP payload something that the WG would support?


regards,

--
regards,
RayH

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

Re: [homenet] IPv6 & firewall config in a home net

[Ray Hunter (v6ops)]

Mikael Abrahamsson wrote on 06/09/2019 08:59:

On Thu, 5 Sep 2019, Ray Hunter (v6ops) wrote:

IMHO Expected behavior. Many European data protection people consider 
an IP(v6) address to be privacy-sensitive personal data. That will 
likely mean regular renumbering of IA PD by ISP's as the norm rather 
than the exception.


This is the first time I've seen anyone make this claim (I guess 
related to GDPR). I've gone through GDPR review and talked to others 
who have done the same, and I from a GDPR point of view there is no 
reason to renumber on a regular basis. From what I can tell, 
renumbering at some frequency makes no difference from a GDPR point of 
view. The addresses are privacy sensitive regardless if you change 
them frequently or not.

This last sentence is key.

FYI The opinion I read was as follows:

"The same also applies to IP addresses. If the controller has the legal 
option to oblige the provider to hand over additional information which 
enable him to identify the user behind the IP address, this is also 
personal data."


So if the provider intentionally destroys any method of linking an IP 
address to a user behind an address (by regularly renumbering using 
pseudo-random prefixes) then by the opposite argument the IP address 
shouldn't be considered personal data any more.


This is a method that I've also seen used to pseudo-anonymize MAC 
addresses logged via wifi in a building management system. The MAC 
addresses were hashed with a pseudo random key that rotated every day, 
and the key was not stored anywhere. So the location data could be 
tracked accurately for an individual device over a period of 24 hours, 
but the privacy people considered this good enough that the result 
wasn't considered as personal data, because there was no practical way 
to work backwards from the hashed addressed to the movements of an 
individual device carried by an individual person.


I ain't a lawyer.


My experience is that the frequent renumbering is a local market 
practice that people in that market got used to. As a swedish user, I 
hadn't heard of this practice until I started talking about these 
things with people that ran/experienced ISPs in other nations. The 
defaults are also different.


Some markets have frequent renumbering (some even reset the PPPoE 
session once per day, which is a flash renumbering eevent), some never 
renumber unless there is a big network change (I've had the same IPv6 
prefix now for a year).


The conclusion is that we need to create solutions that handle both 
these cases.


I agree with your conclusion, so the rest is pretty much a moot point 
for Homenet.




--
regards,
RayH
<https://www.postbox-inc.com/?utm_source=email_medium=siglink_campaign=reach>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] IPv6 & firewall config in a home net

[Ray Hunter (v6ops)]

Ted Lemon wrote on 05/09/2019 18:31:

On Sep 2, 2019, at 1:47 PM, Michael Richardson  wrote:

Assuming that the prefix change is make-before-break (which we do not clearly
know how to do on the WAN side, I think), then the web server should
configure with the same rfc7212 IID, but a new prefix.

I don’t think there’s any need for the IID to be persistent.   
Make-before-break is accomplished by deprecating the old prefix when the new 
prefix is added.   This is trivial to do; whether it is in fact done is a 
different matter.   I think that at present the client would have to notice 
that it’s happened.


Agreed.

Using RFC7217 will anyway almost certainly guarantee that the IID will 
also change if the prefix changes.


The prefix is included in the function that generates candidate IID's.

  RID = F(Prefix, Net_Iface, Network_ID, DAD_Counter, secret_key)


That was done to prevent tracking when people move between wifi hotspots.

--
regards,
RayH

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

Re: [homenet] IPv6 & firewall config in a home net

[Ray Hunter (v6ops)]

mal.hub...@bt.com wrote on 02/09/2019 17:55:


Hey,

Mal here. IETF attendee since 2012 ;)

I have a home networking question with respect to IPv6 standards, I’m 
hoping to use you as a sounding board first before I take it to v6ops.


The scenario here is a home / soho network situation where the user 
wants to host a service, lets say its a webserver, but really could be 
any hosted application, importantly using IPv6. The router is setup to 
use SLAAC only.


The ISP offers IPv6 GUA addressing in a non-stable manor, its "sticky" 
but at some point in the future it might change (BNG reboot for example),


IMHO Expected behavior. Many European data protection people consider an 
IP(v6) address to be privacy-sensitive personal data.
That will likely mean regular renumbering of IA PD by ISP's as the norm 
rather than the exception.


so the user will use DynDNS provider to provide a stable name for 
their service, this sounds OK so far.


External users should also be using a name rather than a (time variant) 
IPv6 address.


Please be so kind as to review our draft 
https://tools.ietf.org/html/draft-ietf-homenet-front-end-naming-delegation-08


[Hopefully a new version will be forthcoming soon]

This is precisely one of our use-cases.

The user has to allow the webserver port, 443 in their router GUI 
firewall to allow the traffic in, sounds simple enough. Importantly it 
should be to that webserver device only.


Now the tricky part….

Since in this scenario the webserver device is using privacy 
extensions, it has a bunch of IPv6 GUA addresses and no EUI-64 and


- It has Temporary addressing (which will regularly change)

- It has a "Permanent" address (which is the one the webserver will 
want to use)



The webserver should not be using privacy extensions for inbound sessions.

It really should be using https://tools.ietf.org/html/rfc7217


Does this sound reasonable and make sense so far ? Cool.

In the router GUI the user is presented with a list of "devices" for 
which the router can open up TCP 443 in the firewall.


It is reasonable to assume the user does not want to type in the 
Permanent IPv6 address of the device, as it is poor CX and anyway it 
will change in the future (possibly due to a network change / BNG 
restart etc as mentioned)



Correct.


Current routers on the market I have come across have either:

 1. Open the port to the current temporary address only which means
that inbound connections on the port usually fails right away (if
the webserver is not listening on that address) – or fail after
the temporary address changes.
 2. Opens the port to the correct address (by chance)
 1. - But then fails at some point in the future when the network
prefix changes (as router drops the rule when the prefix changes).
 3. Opens the port to some or ALL addresses currently (& sometimes
historically) associated with the mac address of the device  (not
great for security – spoofing? )
 1. But even that sometimes excludes the permanent address
 4. Opens the port to all addresses on LAN (not great for security at all)

  * Basically the routers firewall config gui doesn’t know reliably
which device address is the permanent one. 


  * Should there exist a mechanism to signal to the router or the
router can accurately learn which of the devices addresses should
be used for configuration in the firewall ?


Yes. via PCP RFC6887 et al.


 *


Is this a problem – have I missed something – Is it worth fixing ?

Yes. - RFC8520? although there's still a gap for policy IMHO (does a 
user want to accept what the manufacturer suggested) - Yes.


Thoughts:

This is probably a strange thing for the user to do (but I have had 
users trying to do it). Its usually fixed for a customer by switching 
off privacy extensions / using EUI-64 so basically giving the device a 
single address for the router gui to identify the device by.


I personally hope this becomes more common, to avoid the need for NAT, 
rendezvous points, dependence on central certificate instances etc.


Mal



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


--
regards,
RayH

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

Re: [homenet] [EXT] securing zone transfer

[Ray Hunter (v6ops)]

Hi,

Ted made a valid point about "running code" in this thread.

So I've been experimenting with various configurations.

My conclusions:

1) We definitely need to properly secure communication between the HNA 
and the DM for control traffic.


This needs to be an explicit part of the draft.

2) Authentication based on the physical connection, plus source IP 
address, plus correlation of the source address against the contents of 
the RR *might* be sufficient for transactions between the HNA and the DM 
for reverse zones - all communication is guaranteed to be contained 
within a single AS.


Current best practice of using IP ACL's + BCP 38 for filtering 
communication could work in this case. The DM would then check whether 
the contents of the PTR updates arrived from a source address associated 
with the HNA.


We'd need to add some text saying the HNA should select source addresses 
for reverse zone updates appropriately (to make sure the updates came 
from an address issued via IA-PD from this ISP).


3) for communication between the HNA and a DM for forward zones, we 
definitely need to specify something stronger, because the DM 
potentially has to serve HNA's scattered over the entire Internet.


4) TSIG isn't going to scale operationally IMHO.

Too many keys to manage. Keys have to be stored on line within the DM. 
Losing keys means compromising the whole service, and it is difficult to 
recover from.


5) SIG(0) has similar problems.

Bootstrapping the trust might mean the expiration time would have to be 
so large that replay attacks will come into play.

And recovery is difficult.

6) DNS over an existing standard FOO secure transport looks promising.

The amount of traffic arriving at a DM should not be so large or time 
critical as the traffic to the resolvers, and capacity can be scaled by 
increasing the numbers of DM's.


There is also existing front-end hardware acceleration available. So the 
secure transport could theoretically be terminated on an dedicated 
acceleration box, and the DM only then needs to speak native DNS.


7) DNS over TLS can almost certainly be made to work without any new 
standards, but it will require extensive coding as support seems pretty 
limited off the shelf.


It also has the added benefit that client authentication can be built 
into the transport.


So I've been playing around with the DM being authenticated by public 
certificates to the HNA (HNA would incorporate root certificates burned 
in at the factory), and the HNA being authenticated to the DM by a 
client-specific certificate that is signed using a self-signed 
intermediate CA certificate from the DM. The DM then trusts the 
certificates it has issued to the client HNA's simply by installing the 
root CA cert on the DM: there's no client specific configuration required.


Since the HNA anyway has to be configured to use the DM, and some trust 
has to be  established, I don't see this as an onerous burden in the 
sign up process.


8) DNS over HTTPS doesn't bring us anything extra in this case IMHO.

It actually presents additional challenges with coding alternate 
transports and parsing (POST or GET HTTP1.1 HTTP2) etc.

Others may disagree, so the draft could use a "recommend DNS over TLS"

9) IMHO we should also standardize the trust-booting process into a JSON 
file, that can either be fetched via HTTPS or pasted into the HNA.


This for the same reasoning for inter-operability that DNS standardized 
the file representation of the zone file in RFC1035 Section 5.


For a start, I came up with the following, although I'm sure we can 
improve as we get more experience in what parameters are needed for each 
implementation.


I came up with 4 parameters:

dm_axfr    fqdn of the DM for axfr (so the HNA can apply IP filters on 
inbound requests)


dm_ctrl    fqdn of the DM for ctrl (so the HNA can send updates to the 
DM control channel e.g. if the HNA renumbers it would send an NS record 
and  record update)


zone    the zone that is being delegated

hna_certificate    client certificate encoded as a single line with 
literal '\n' replacing cr and lf characters (common practice in existing 
equipment when pasting certificates)


This would also work for a reverse zone, although obviously it's a 
different DM etc.


Sample:

{"dm_axfr":"dm.homenetdns.com","dm_ctrl":"dm.homenetdns.com","zone":"sub.homenetdns.com","hna_certificate":"-BEGIN 

Re: [homenet] securing zone transfer

[Ray Hunter (v6ops)]

Michael Richardson wrote on 13/06/2019 03:25:

Juliusz Chroboczek  wrote:
 > Are you assuming here there's a central Homenet controller that presents
 > a web interface where the "house owner" can choose which names get
 > published?

No, we are assuming that there are one or more homenet routers that either
come with a delegated domain from the manufacturer (probably a very ugly
one), or which that CPE's ISP will delegate via DHCPv6. (or both)

Whether we should or have to do some negotiation over HNCP if there are
multiple CPEs is a problem we can deal with later.

We have, however, been thinking about the problem of having partial
connectivity for the home, and how do published names get resolved.

 > I'm probably missing something, Michael, so please explain if you agree
 > with the analysis above, whether you're assuming a central controller,
 > and, if so, where is the central controller located in a network that has
 > multiple edge routers.

If an end user wants a non-ugly domain, and they buy it, then they need to
introduce one or more of their CPEs to the upstream provider of the
domain.  It could be it is at this point that it makes sense to do some HNCP,
but in essence, this is an internal problem, and the front-end-naming
document is not about internal issues.

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



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


Indeed this draft should say as little as possible about what should 
happen internally (whether there's one elected central Homenet 
controller for all ISP uplinks, or there's something running on all 
Homenet routers that updates an edge HNA per ISP uplink, or the HNA 
service runs on a host, or something else).


Probably the text isn't in that state yet.

The facts of life with using DNS are that:
- a zone delegation is built on a hierarchical name space with a single 
root;

- a delegated zone is a proper subset of a parent zone,
- zone signing occurs with one single active zone signing key signing 
the complete set of RR's in a zone (not a key or signature per RR), and 
where
- zone transfer updates are performed with a master/slave arrangement 
with a limited number of known peers per zone.


If you want individual hosts to interact directly with an outsourced 
name service based on DNS (instead of via an HNA), you either have to 
delegate the zone signing to the outsourced name service (which 
introduces a different trust model), or you assign a dedicated zone per 
host (possible?), or you introduce a massive key sharing and signing 
problem.





Another use case could be small companies who want to run something like 
Active Directory on premises (AD integrated DNS).


Then they could potentially build AD forest trust relationships between 
companies.


AD of course runs on a domain controller (DC). The DC function could 
then potentially take on the role of HNA, whether that is running a 
separate server or on a CPE.


--
regards,
RayH

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

Re: [homenet] securing zone transfer

[Ray Hunter (v6ops)]

Inline. Long post.

Juliusz Chroboczek wrote on 12/06/2019 04:03:

Actually, it's fatal, because you can't get a certificate for "boombox.local"
so you can't secure it that way.  So you always have to use the FQDN.

That sucks, of course, but the problem is completely unrelated to being
published in the global DNS -- the very same problem applies to names that
only appear in local MDNS.

No. They are directly related. See below.

I think that's our main disagreement.
For some reason, you guys seem to be assuming that the average user will
want to publish hundreds of names in the global DNS.

Hundreds?  How about two.
My son wants to publish his desktop's name so that his friend can reach his
system directly for minecraft.  I want the same.

Your son clicks "publish name" in the Minecraft server's UI, at which
point he faces the following dialog box:

   Domain: dyndns.minecraft.example.com
   Hostname: minecraft-7ac8
   Password:

The young man considers that default values are for noobz, and edits as
follows:

   Domain: richardson-family.vanity-dyndns.example.com
   Hostname: better-server-than-dads
   Password:

After the name is published (which takes half a second), the Minecraft UI
displays a "share" icon, so that your son can publish the server's name
over UUCP, or whatever it is that them youngsters use nowadays for chatting.

Your turn now.  Could you please describe the UI that you envision?

-- Juliusz


It would seem your objection can be summarized as "we don't need this". 
Correct me if I'm wrong.


To me is like saying we don't need a new routing protocol like BABEL, 
because we have loads of routing protocols already.
[for the record I strongly supported incorporating BABEL into Homenet, 
because to me it was the best choice]


Funnily enough my next door neighbor (who knows nothing about 
networking) could appreciate the use case.


He can currently control his central heating system from his smartphone. 
But he needs to pay for the rendezvous service, or has a tie in to a 
particular heating-system maintenance provider.


The use case would then be that an IoT device or local gateway device 
could use one common protocol (out of scope) to talk to the Homenet 
router, then the homenet router could publish and resolve names to 
backbone DNS infra, whilst the app developer wouldn't need the 
rendezvous service or NAT traversal. The rendezvous service is also a 
single point of attack for large scale DDOS, and also might raise 
privacy concerns because the manufacturer can monitor detailed use of 
all the devices they've sold. Mobile devices could use one single name 
to connect to the gateway device in a secure manner from anywhere.


So rather than being forced to use the manufacturer's thermostat, or 
sign a service contract from a particular maintenance provider tied to 
the manufacturer, he can use OpenTherm, and he can control OpenTherm 
from anywhere.


Yes, there are HTTP REST interfaces to accomplish this, but they ain't 
standard, and they ain't always easy to use.
[check out comments from people who've tried to automate this for 
multiple alternative REST-based providers]


Yes, each individual device could also manage names directly with 
multiple DNS outsourcing providers, but then you potentially create an 
explosion of keying and signing material if you want DNS-SEC to work in 
any meaningful way.


Especially as DNS is becoming more of a trust anchor for other services.

How much easier is it to trust devices using TLS over a self-signed 
certificate anchored via TLSA records to DANE on your own DNS zone?


accept TLS from any devices with certificates with CN 
*..homenet.com
accept TLS from any devices with certificates with CN 
*..homenet.com

deny all

Then the minecraft connection with your friend can be properly secured 
without resorting to chat protocols and shared secrets or IP filters.


You don't need to pay a CA for any magic beans because DANE will work 
with self-signed certificates, even in a chain (mode 2 trust anchor). 
And you can be sure no-one has messed with the certificate, because 
you've created the certificate yourself, and you've signed the DNS zone 
yourself with your own private keys that haven't been shared with anyone 
else. Sure, you still have to bootstrap all of this.


To me it seems obvious that people should be able to distribute services 
(if they want to) to their own network.
If they want to rely on the handful of technology giants for their 
security, then fair enough. But they should have a choice.


regards,
RayH



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


--
regards,
RayH

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

Re: [homenet] [EXT] securing zone transfer

[Ray Hunter (v6ops)]

Thanks for the feedback.

> first, the gateway does not know for sure which external NS are use 
by the secondary DNS service,


Agreed. The draft needs to address how the service is boot-strapped and 
auto-configred.


> second the IPs of the WAN port might not be the internet facing IPs 
and this could break inbound connectivity


I hope that we're going to be able to move past IP filtering as the 
primary security mechanism for this draft.


Especially in the presence of renumbering.

regards,

Jacques Latour wrote on 11/06/2019 20:59:


Daniel,

In trying to setup our secure home gateway project to have the 
external zone & primary DNS server setup and managed on the gateway 
itself and to XFR back to secondary name servers somewhere turned out 
not be functional or practical, first, the gateway does not know for 
sure which external NS are use by the secondary DNS service, second, 
the IPs of the WAN port might not be the internet facing IPs and this 
could break inbound connectivity.  We’re looking at using dynamic DNS 
updates for things that need internet connectivity, and have the 
primary DNS server on the main land.   TSIG & DNS over TLS look like a 
good option to look at.


Jacques

*From:*homenet  *On Behalf Of *Daniel Migault
*Sent:* June 7, 2019 4:03 PM
*To:* homenet 
*Subject:* [EXT] [homenet] securing zone transfer

Hi,

The front end naming architecture uses a primary and a secondary dns 
server to synchronize a zone. The expected exchanges are (SOA, NOTIFY, 
IXFR, AXFR. We would like to get feed backs from the working group on 
what are the most appropriated way to secure this channel.


Options we have considered are TSIG, IPsec, TLS, DTLS. TSIG does not 
provide confidentiality, and we would rather go for user space 
security.  Are there any recommendation for using TLS or DTLS in that 
case ?


Any thoughts would be helpful.

Yours,

Daniel



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


--
regards,
RayH

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

Re: [homenet] primary / secondary configuration

[Ray Hunter (v6ops)]

Daniel Migault wrote on 07/06/2019 22:27:

Hi,

We are looking for a simple way to configure the primary / secondary 
DNS setting between the homenet and the outsourcing infrastructure. 
The exchange of these information is done over a secure channel - let 
say TLS. While we coudl re-define a configuration template / mechanism 
we believe that re-using widely deployed libraries would ease the 
deployment.


The HNA is responsible for building / signing the zone and 
synchronising the zone with the outsourcing infrastructure. To build 
the zone some elements of the infrastructure are needed such as the NS 
and IP for example. One way to enable the transmission of information 
from the the outsourcing infrastructure to the homenet is to use an 
well known fqdn hna.example.com  with an AXFR 
request. Does it sound reasonable ?




Stating the obvious: if an HNA is going to sign a zone, it has to own a 
globally unique delegated zone.


I see 3 ways of delegating a piece of namespace and gathering the input 
for the SOA:


1) HNA is pre-configured with one or more DNS outsourcing providers in 
the admin GUI e.g. .


User picks one via LuCI.

HNA creates a proposed zone name e.g. . or asks for 
a proposal from the user.


DNS Outsourcing Infra confirms that . is unique via 
the parent zone 


2) HNA is pre-configured with one or more DNS outsourcing providers in 
the GUI e.g. .


User picks one via LuCI.

HNA contacts .

HNA receives the zone name  . from the DNS 
Outsourcing Infra.


3) HNA owner purchases a nice name from a registrar e.g. 
. Domain Registrar and the DNS Outsourcing Infra 
example.com, don't share a common parent zone.



IMHO for (1) and (2) we already have working outbound DNS resolution in 
place, and the HNA can gather SOA variables using either a simple SOA 
lookup of the parent zone, or via a SOA + and AXFR to fetch a template.


(1) dig -t soa example.com +dnssec -> NS1 NS2 +  RR + timers of the 
parent -> copied 1:1 to the child zone .example.com.

Obvious disadvantage: everyone is tied to the same infra, timers, and NS RR.
Advantage: cheap and cheerful.

(2) dig -t soa example.com +dnssec|perl extract_MNAME_from_SOA.pl; dig 
@$MNAME -t axfr .example.com +dnssec|perl extract_SOA_variables.pl;


The MNAME in example.com SOA would contain the name of the DM config 
server/template server.


The DM config server/template server would either have to generate the 
template on the fly, or have one pre-configured during sign up.


(3) would have to be out of band or require something much more complex.


On the other hand, the outsourcing infrastructure needs to know the 
fqdn of the hna. One way to provide that information could be to 
re-use DNS update updating the SOA of hna.example.com 
. The fqdn of the hna would be indicated 
using the MNAME field. Does it sounds reasonable as well ?


Yours,
Daniel




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


--
regards,
RayH

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

Re: [homenet] securing zone transfer

[Ray Hunter (v6ops)]

Ted Lemon wrote on 08/06/2019 05:50:
On Jun 7, 2019, at 11:36 PM, Michael Richardson > wrote:
Can we use TLS for authorization, assuming that we have trusted 
certificates

at both ends?  Perhaps this is more of a: did anyone implement this?


How is trust established?   Sure, doing TSIG over TLS is no problem.


Bootstrapping trust is always going to be an issue no matter what we do.

There can be multiple ways to bootstrap this, and multiple possible 
providers pre-configured in the GUI.


Possible alternatives for further investigation:

1) something burned in at manufacturing time + trust between the 
manufacturer and the DNS Outsourcing Infra provider.


An initial query from the HNA to the infra could include a proposed 
domain name e.g. an AXFR or SOA query for .example.com sent to 
the DM together with SIG(0) signing of this name.


The signing could be done by a private key held at the manufacturer.

SIG(0) doesn't protect the wrapper, only the query data, so the query 
can be signed in advance off-line before anything like the homenet IP 
address is known.


The DNS outsourcing infra can check this signature either using an 
associated public key that is hosted on the manufacturer's DNS in a 
pre-agreed location. e.g. homenet-keys.manufacturer.com. Or the 
manufacturer could pre-share this public key with the DNS outsourcing 
provider out of band.


2) Out of band sign up using a public/private key held at the DNS 
outsourcing service provider at service sign up time (https + credit 
card + CGI script on the service provider's web site -> delegated domain 
name + SIG(0) signed delegated domain name query on the HNA for the 
initial query to the DM). The DM only needs to know the current valid 
public keys used for the SIG(0), and the private key and credit card 
details can be held elsewhere and regularly rotated.


3) Trust based on the TLS + certificate chain, rather than anything at 
the DNS application level. Currently very much hand waving on my part up 
until now. I've seen DANE being able to validate TLS connections based 
on a certificate chain (e.g. RFC 6698 DANE-TA(2) Trust anchor assertion, 
with a common trust anchor like let's encrypt X3 root) and was thinking 
we could leverage that somehow for mutual authentication, along with 
perhaps DNS over HTTPS (RFC8484). On the DM end that could use standard 
TLSA records published in the parent zone to validate the DM to the HNA. 
In the other direction we'd have to somehow to process a certificate 
from the HNA to identify the manufacturer or end user to the DM. But 
that's a well-known problem in web server land.


Thoughts?

--
regards,
RayH

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

Re: [homenet] About Ted's naming architecture presentation and document

[Ray Hunter (v6ops)]

james woodyatt wrote:
On Nov 16, 2016, at 17:31, Michael Richardson > wrote:


But, do you agree that publishing your home lighting controller to 
the DNS is

how you manage to control your lights from your phone when you are out of
wifi distance, as you roam to 3G. (I switch to 3G when I get to the 
front of

my rather modest driveway, as the AP is in the back of the basement)?


If anybody is currently shipping, or has announced plans to ship, any 
kind of home automation device that does this, please speak up on the 
mailing list. I’d like to calibrate my perhaps mistaken apprehension 
that nobody would seriously consider doing this. Everyone I know in 
this field plans to do this by providing a single public rendezvous 
point with high availability servers that communicate in turn to home 
automation controllers acting as private clients.



--james woodyatt >



RFC3724.

>  End user choice and empowerment, integrity of service, support for 
trust, and "good network citizen behavior" are all properties that have 
developed as a consequence of the end-to-end principle.


Rendezvous points are themselves an attack vector/ anti-privacy snooping 
vector/ commercial lock-in/ convenience, depending on your point of view.


So please let's empower the end user to either "opt in" or "opt out".

--
regards,
RayH

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

Re: [homenet] Updating DNS [was: How many people have installed the homenet code?]

[Ray Hunter (v6ops)]

Ted Lemon <mailto:mel...@fugue.com>
14 May 2016 15:18
The only problem with that is that in the homenet ideally we'd like to 
have local names signed and validatable via DNSSEC, and that requires 
that the local namespace be global in scope, even if the names 
published in that namespace are not.



Not necessarily.

You only need global scope namespace if trust also needs to extend 
beyond Homenet.


If we're assuming that ULA will be used for on-Homenet communication 
streams (in the event of non-availability of GUA/ ISP uplink), then 
tying local names into the upstream global namespace is not strictly 
necessary.


So IMHO it would be just as acceptable to sign RRs for local names 
related to ULA address space with a locally-generated trust anchor 
(independent of the trust anchors installed on the Internet root servers).


Nodes and new routers would have to learn their local trust-anchor when 
connecting to the Homenet for the first time.


In other words, the local DNSSEC trust anchor identifies a Homenet. Not 
the ULA. Not an arbitrary label.


Otherwise we're going to need a globally-unique time-invariant label to 
identify this Homenet, that is also not based on the actual chosen ULA 
in use, which is not easy to generate.




Ray Hunter (v6ops) <mailto:v6...@globis.net>
14 May 2016 14:51


Ted Lemon wrote:


If devices publish keys, then you can use those keys to make sure you 
are still talking to them. And the dnssec validation of local names 
would also work. Graceful renumbering should indeed result in DNS 
updates. Bear in mind that this is graceful, so the old and new ULAs 
coexist for a while.




Sounds good.

So can we assume

1) a single ULA namespace for resolving all active ULAs, that will 
eventually converge to only containing RRs from a single ULA?


2) And that ULA namespace is disjoint from/completely independent of 
any GUA namespace?





--
regards,
RayH
<https://www.postbox-inc.com/?utm_source=email_medium=siglink_campaign=reach>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Updating DNS [was: How many people have installed the homenet code?]

[Ray Hunter (v6ops)]

Ted Lemon wrote:


If devices publish keys, then you can use those keys to make sure you 
are still talking to them. And the dnssec validation of local names 
would also work. Graceful renumbering should indeed result in DNS 
updates. Bear in mind that this is graceful, so the old and new ULAs 
coexist for a while.




Sounds good.

So can we assume

1) a single ULA namespace for resolving all active ULAs, that will 
eventually converge to only containing RRs from a single ULA?


2) And that ULA namespace is disjoint from/completely independent of any 
GUA namespace?



On May 13, 2016 06:45, "Ray Hunter (v6ops)" <v6...@globis.net 
<mailto:v6...@globis.net>> wrote:




Ted Lemon <mailto:mel...@fugue.com>
12 May 2016 15:48
As long as the renumbering process is clean, there is no downside
to renumbering, and no reason to be careful about which ULA you
ultimately wind up with.


So are you suggesting the Homenet (internal) namespace should be
independent of ULA address space?

In which case

1) how do we avoid the ".local" security problem where mobile
devices are unable to distinguish whether they've actually moved
to a different Homenet, or whether they've stayed still and their
own Homenet has just renumbered.

Or else

2) Does the renumbering mechanism also trigger an automatic
renaming too?

-- 
regards,

RayH

<https://www.postbox-inc.com/?utm_source=email_medium=siglink_campaign=reach>



--
regards,
RayH
<https://www.postbox-inc.com/?utm_source=email_medium=siglink_campaign=reach>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Updating DNS [was: How many people have installed the homenet code?]

[Ray Hunter (v6ops)]

Ted Lemon 
12 May 2016 15:48
As long as the renumbering process is clean, there is no downside to 
renumbering, and no reason to be careful about which ULA you 
ultimately wind up with.


So are you suggesting the Homenet (internal) namespace should be 
independent of ULA address space?


In which case

1) how do we avoid the ".local" security problem where mobile devices 
are unable to distinguish whether they've actually moved to a different 
Homenet, or whether they've stayed still and their own Homenet has just 
renumbered.


Or else

2) Does the renumbering mechanism also trigger an automatic renaming too?

--
regards,
RayH

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

Re: [homenet] Updating DNS [was: How many people have installed the homenet code?]

[Ray Hunter (v6ops)]

Juliusz Chroboczek 
12 May 2016 15:10
If I'm reading you correctly, Ray, you're promoting unstable naming.

Not promoting. Looking at the consequences.

   If
I have two routers called trurl and pirx in my network, then my printer
will becalled diablo630.pirx.home whe pirx is up, diablo630.trurl.home
when trurl is up, and either I reconfigure all of my hosts every time
I swap a router, or rely on the DNS search list being correct?


We have multiple independent address spaces (ULA per router + GUA per
provider),

actually I was thinking more along the lines of the printer being called

diablo630.default_zone.ula1.home (ULA1)

and

diablo630.default_zone.ula2.home (ULA2 if it exists)

and

diablo630.my_isp1.com (GUA1)

and

diablo630.my_isp2.net (GUA2)


simultaneously.

The DNSSL would indeed be updated automatically when the homenet 
autoconfigures, and advertised by RA.


The name registration and resolution for the various namespaces could 
run independently.

No, we have a GUA per provider, and *optionally* a single ULA for the
whole Homenet:

   An HNCP router SHOULD create a ULA prefix if there is no other IPv6
   prefix with a preferred time greater than 0 in the network.  It MAY
   also do so if there are other delegated IPv6 prefixes, but none of
   which is locally generated [...]  In case multiple locally generated
   ULA prefixes are present, only the one published by the node with
   the greatest node identifier is kept

Thanks for that explanation.

If a new router is added, a new ULA is added,


No, that's not the case.
What happens if that new router has been booted stand-alone (so it 
creates its own ULA), and then joins the Homenet by being plugged in, 
and has a higher node identifier?


Shouldn't this be a voting mechanism to retain the "most popular" 
existing ULA?

If a router is removed or dies, the ULA prefix expires


Nope.  If a router dies, any ULA should remain stable, even if it's the
router who originally generated the ULA that dies:

When a new ULA prefix is created, the prefix is selected [...] using
the last non-deprecated ULA prefix

That's the whole point of using a ULA.
Well even then you have the corner case of a split, stable operation, 
remerge, where one of the two ULA prefixes will disappear.


If the namespace relies in any way on the ULA, it'll change if the ULA 
changes.


If the namespace doesn't rely on the ULA, we'll likely get hit by the 
same (security) problems as mobile devices moving between disjoint 
.local networks.


Or else we have to manually configure a "Homenet root name"/ "Homenet 
identifier"?


Thoughts?

--
regards,
RayH

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

Re: [homenet] Updating DNS [was: How many people have installed the homenet code?]

[Ray Hunter (v6ops)]

Ted Lemon 
11 May 2016 20:03
DNS update is pretty simple.   Any problem with using that?

Not with the update mechanism itself


I think you may be slightly conclusing "authoritative" and "primary." 
  There is no need to elect authoritative servers--just make them 
secondary to the elected primary.   You can't have two primaries with 
stock DNS--that's probably the biggest fly in the ointment.



Exactly.

The challenge is the Homenet requirement to support network segmentation 
and remerging.


We have multiple independent address spaces (ULA per router + GUA per 
provider), so why not multiple namespaces?


If a new router is added, a new ULA is added, together with associated 
namespace, and infra.
If a router is removed or dies, the ULA prefix expires, together with 
associated namespace and infra.


If a new ISP uplink is added, a new GUA is added, together with 
associated (upstream) (globally resolvable) namespace and infra.
If an ISP is removed or dies, the GUA expires, together with associated 
namespace and infra.


Then the namespace infra/ update server could be tightly bound to the 
device that delegates/creates it (either the homenet router, homenet 
border router, or the ISP infra)


I know people don't like DNS search lists, but they do work, and are 
widely supported. Or else a recursive resolver running on the local 
homenet router could handle the search work for the end hosts.


I also realize this creates a new challenge of how to update all of 
these various namespaces.


The reason to have a hybrid proxy is because we have to support 
existing devices.   Clearly it's not the right long-term solution, but 
we can't force vendors to implement something new if they don't want to.





--
regards,
RayH

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

Re: [homenet] Updating DNS [was: How many people have installed the homenet code?]

[Ray Hunter (v6ops)]

Juliusz Chroboczek 
11 May 2016 18:29

Bonjour is (roughly) based on Appletalk AFAIK. I've got nothing against
Appletalk Phase II, so if Bonjour was extended to provide an equivalent
function to Appletalk Phase II Zone Information Protocol = ZIP then I'd be
happier. That would cover concerns on non-overlapping name spaces. And
Appletalk NBP/ZIP resolution also prevents loops in routed networks.


« The AppleTalk Zone Information Protocol (ZIP) manages the relationship
   between network numbers and zone names. »

While I could in principle go and pick a copy of Inside Appletalk at the
library, I'd be grateful if you could explain what you have in mind.
I do happen to have a (yellowed) copy of "Inside Appletalk" on my 
bookshelf ;)


It would be new functionality to Bonjour, so strictly speaking it's out 
of scope for Homenet.


AFAIK (and I'm sure someone will keep me honest here) Appletalk strongly 
binds network numbers/cable ranges (prefixes in IPv6) to zones (logical 
groupings). Zone associations to network numbers/links are controlled by 
the Appletalk routers (not the hosts directly) and are associated with 
either a logical or physical link. The routing of name resolution 
requests to (extended) networks is based on zones. There can be multiple 
zones per network number, but the first zone is the "default zone" that 
hosts should use if they have no other preference. Host interfaces can 
only have a single network address and be a member of a single zone 
(although I've never actually seen that defined anywhere).


I leave it as a discussion point of whether that's a good model for 
Homenet, especially since IPv6 explicitly supports multiple prefixes per 
link and multiple addresses per interface per host.


Allowing a tight binding of IPv6 prefix <-> Homenet namespace zone could 
possibly work and simplify any solution for e.g. reverse resolution.


The key characteristics (that currently seem to be missing) would be:

1) a mechanism to route name resolution requests in an L3 network

2) a mechanism to prevent/ mitigate the effect of any (transient) loops 
in the name resolution infra (could be sub-function of 1)


3) a mechanism to advertise "zones" between Homenet routers.

4) a mechanism to advertise zones to hosts.

5) a field to indicate "zone membership" of a particular name/label to 
be used by hosts when advertising/resolving names.



I don't like the hybrid proxy model either.  It promises the union of
the problems and intersection of the functionality.  Proxying flies in
the face of the trend of smart devices and dumb networks.


Very well put.

-- Juliusz


--
regards,
RayH

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

Re: [homenet] Updating DNS [was: How many people have installed the homenet code?]

[Ray Hunter (v6ops)]

Ted Lemon 
11 May 2016 18:37

> I don't like the hybrid proxy model either.  It promises the union of
> the problems and intersection of the functionality.  Proxying
flies in
> the face of the trend of smart devices and dumb networks.

Very well put.


Be that as it may, Homenet in general flies in the face of that trend. 
  And if you think about it, that trend isn't really a very smart 
trend, because the burden it places on devices is extreme, and not all 
devices have infinite resources to spend mapping the network and 
figuring out how to publish their services on it.


But if we were to build a smart network from scratch, I also wouldn't 
start with proxies, nor maintain a distributed database in the hosts.


I'd start with letting the routers build a naming infra, together with 
defining a (simple) name registration protocol between host and on-link 
router(s) (together with conflict resolution to communicate "sorry, that 
names already taken")


And the starting point would then probably be HNCP + DNS to elect a max 
of 'n' authoritative name servers per homenet, where 'n' NS and  
records can fit it a single UDP packet.


So whether you prefer a "smart host" or "smart network" model, hybrid 
proxies seem a poor compromise.


--
regards,
RayH

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

Re: [homenet] Updating DNS [was: How many people have installed the homenet code?]

[Ray Hunter (v6ops)]

On 11 May 2016, at 15:01, Ray Hunter (v6ops) <v6...@globis.net 
<mailto:v6...@globis.net>> wrote:


Tim Chown wrote:
On 25 Apr 2016, at 03:39, Ted Lemon <mel...@fugue.com 
<mailto:mel...@fugue.com>> wrote:


On Sun, Apr 24, 2016 at 12:29 PM, Juliusz Chroboczek 
<j...@pps.univ-paris-diderot.fr 
<mailto:j...@pps.univ-paris-diderot.fr>> wrote:


> Juliusz, the problem is that existing home network devices that do
> DNS-based service discovery do not support DNS update. They
could, but
> they don't, because we didn't define an easy way for them to
do it.

I'd be grateful if you could expand on that.  Why can't we
define a way
for clients to do DDNS?


We can and should.   The problem is that we won't see that code 
ship in new devices anytime soon, so we still have to make mDNS work.


And this is why the dnssd WG is focused on making mDNS work on 
multi-subnet networks.

That to me seems to be putting pragmatism before requirements.


To an extent it is. The Bonjour protocols are much more widely 
implemented and deployed than DNS Update.


Yes. I've seen a lot of printers shipping with it, and it works great at 
that scale.


I've also seen enterprises working with fully integrated DNS, together 
with managed Windows Domain Controllers, at monster scale.


Homenet is somewhere in the middle: we have more complexity, but no 
"computer certificates" to fall back on.


I'm not entirely convinced by the dnssd work, and have said so on the 
relevant WG.


Do you mean the need for it based on Bonjour, or the solution given 
we’re building on that?

Both.

Bonjour is a great protocol for a flat L2 network.

Bonjour is not designed for L3 networks (no inherent hop count, nor loop 
protection), nor support for multiple/overlapping name spaces.


The Homenet architecture calls for administrative zones.

I may have a guest LAN.
I may have a printer LAN (that is shared with guests)
I may have a media server (which is not shared with guests)

The Homenet architecture calls for multiple upstream providers.

I may have an electricity provider who allows me some special log on via 
the power network to control home automation, or feed back from my solar 
panels. They may publish (private) names for use by contracted customers 
that are not available over the Internet. Yes, that could also be done 
over Internet, but a specialised "walled garden" could be so much more 
secure and less vulnerable to external disruption.


Bonjour is (roughly) based on Appletalk AFAIK. I've got nothing against 
Appletalk Phase II, so if Bonjour was extended to provide an equivalent 
function to Appletalk Phase II Zone Information Protocol = ZIP then I'd 
be happier. That would cover concerns on non-overlapping name spaces. 
And Appletalk NBP/ZIP resolution also prevents loops in routed networks.


Otherwise I struggle to map the Homenet requirements onto the solution.

[BTW for the record, I don't consider DNS "as-is today" a great 
contender either. So I'm not just bashing Bonjour by any means]




Note that one requirement was that other SD protocols could be 
integrated into the hybrid proxy model. That’s still possible, but no 
one has expressed any interest as yet.



I don't like the hybrid proxy model either.

It promises the union of the problems and intersection of the functionality.

Proxying flies in the face of the trend of smart devices and dumb networks.

If you get any device that bypasses, or misunderstands, the proxy 
topology, we could get very nasty name resolution loops [no inherent 
loop protection in Bonjour].


But Ted has raised the question of DNS Update there, and we agreed 
in BA that we’d accept a draft on issues around coexistence of mDNS 
and DNS Update.
If "it" (multi-subnet mDNS) is going to cause more issues down the 
line, is it sensible to pull this into Homenet now?


I think this is why Ted is doing what he is doing.  Homenet is a 
different environment - smaller and unmanaged, generally.



Is that the intended question to be answered by that draft?


The question is what happens in environments where both might mix. 
 Well, that’s one question.  Ted offered to draft a -00 on that topic, 
in one of his spare moments ;)



That seems like a worthwhile draft.


> Just 2136 isn't enfough, because there's no authentication
scheme,

I don't understand this argument.  How is non-secured DDNS any
less secure
than mDNS?  What am I missing?


This is an implementation issue, not a security issue--sorry for 
not making that clear.   In order to preserve the same security 
characteristics that mDNS has, we have to ensure that the update 
actually originated on the local link, which requires a different 
sort of listener than is present in a typical DNS server.   And 
existing DNS servers typically don't have any way to support 
unauthenticated updates on a first-come, first

Re: [homenet] Updating DNS [was: How many people have installed the homenet code?]

[Ray Hunter (v6ops)]

Tim Chown wrote:
On 25 Apr 2016, at 03:39, Ted Lemon > wrote:


On Sun, Apr 24, 2016 at 12:29 PM, Juliusz Chroboczek 
> wrote:


> Juliusz, the problem is that existing home network devices that do
> DNS-based service discovery do not support DNS update. They
could, but
> they don't, because we didn't define an easy way for them to do it.

I'd be grateful if you could expand on that.  Why can't we define
a way
for clients to do DDNS?


We can and should.   The problem is that we won't see that code ship 
in new devices anytime soon, so we still have to make mDNS work.


And this is why the dnssd WG is focused on making mDNS work on 
multi-subnet networks.

That to me seems to be putting pragmatism before requirements.

I'm not entirely convinced by the dnssd work, and have said so on the 
relevant WG.


But Ted has raised the question of DNS Update there, and we agreed in 
BA that we’d accept a draft on issues around coexistence of mDNS and 
DNS Update.
If "it" (multi-subnet mDNS) is going to cause more issues down the line, 
is it sensible to pull this into Homenet now?


Is that the intended question to be answered by that draft?



> Just 2136 isn't enfough, because there's no authentication scheme,

I don't understand this argument.  How is non-secured DDNS any
less secure
than mDNS?  What am I missing?


This is an implementation issue, not a security issue--sorry for not 
making that clear.   In order to preserve the same security 
characteristics that mDNS has, we have to ensure that the update 
actually originated on the local link, which requires a different 
sort of listener than is present in a typical DNS server.   And 
existing DNS servers typically don't have any way to support 
unauthenticated updates on a first-come, first-served basis, so if 
you allow unauthenticated updates, you don't have any way to avoid 
collisions.   Otherwise you are correct.   The answer is to write a 
document that describes how to do that, and if you read the homenet 
naming arch document, you can see that I actually sketched out a 
solution there, which I expect to go in a different document, likely 
in a different working group.


There are many worms in that can :)
I understand that this is potentially a huge can of worms, but if no one 
opens it, it'll never get solved.


So my preference would be to write down what we want in Homenet (in the 
naming architecture document, in a technology-agnostic way), analyse the 
gaps against competing current technologies, and then see what people 
propose to close those gaps.


If multi-subnet mDNS comes out a clear winner, then I'll shut up.

But I'm not even convinced that the gaps are understood/ documented at 
this time.





Oh, sure, we Poles are not quite as pessimistic as the Finns.  I'm
actually of a divided mind here -- I rather like distributed
solutions
(hence prefer mDNS to DDNS) but dislike proxying.  Part of me
just wishes
we'd mandate site-local multicast and do mDNS over that


The problem with site-local multicast for mDNS is that multicast 
isn't a great solution even on the local wire when that wire is 
wireless.And, you have to do modify the client anyway.


Indeed; this was discussed early on in the dnssd WG, and not 
considered for those reasons.


Furthermore, if you consider the mdns hybrid proxy stateless, then 
you can have a DNS server that is roughly that stateless too.   I 
think it provides better service continuity if you are willing to 
retain some state, but everything will still work even if you don't, 
just as the hybrid proxy does.


Agreed.

Tim



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




--
regards,
RayH

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

Re: [homenet] New Version Notification for draft-barth-homenet-wifi-roaming-00.txt

[Ray Hunter (v6ops)]

Mikael Abrahamsson <mailto:swm...@swm.pp.se>
30 Nov 2015 08:33
On Fri, 27 Nov 2015, Ray Hunter (v6ops) wrote:


How would you "move a /64 around"?


Well, the same way you would move a /128 around I guess.


Not sure that's correct.

When moving a /64 per host you have to presume a /64 has been allocated 
to a host already.


So every time a new host joined wifi you'd have to re-run the entire 
HNCP prefix allocation algorithm AFAICS, and check whether there's a 
conflict of this /64 still being active elsewhere. Unless of course you 
pre-allocate a pool in advance assuming there'll be a certain number of 
hosts on wifi.


On the other hand, for moving individual hosts, I've used a CIDR trick 
in the past when moving data centres that 2 or more LANs are configured 
with an identical IPv4 prefix, and then I've added host routes + proxy 
ARP to trick hosts into thinking they're actually directly connected. 
Should also work for IPv6 as long as CIDR is truly 128 bits (RFC7608).


So it seems to me the missing pieces of the puzzle for moving IPv6 /128 
could be:


1. Identifying cooperating router interfaces across the Homenet and 
assigning a common /64 to them in prefix allocation
2. Maintaining a list of /128 wifi hosts bound to the cooperating 
routers interfaces [including MAC address].
3. detecting "side changes" (in bridge speak) where a host has changed 
connection point and packets are arriving on a new cooperating 
interface. Could potentially be detected when receiving a DAD for a /128 
from the list of wifi hosts with identical MAC address to one previously 
observed.
4. injecting and removing /128 routes as hosts move between cooperating 
interfaces, and updating with list of /128 wifi hosts.
5. Proxy ND equivalent to proxy ARP to answer ND requests on cooperating 
router "local" interfaces for hosts connected to "remote" interfaces.


Proxy ND would include DAD [defending a request for a /128 on a 
cooperating interface with a MAC address not included in the list of 
/128 wifi hosts], but also answering standard ND queries AFAICS so that 
wi-fi connected hosts could inter-communicate. Answers to standard 
queries could be triggered by the presence of a /128 route in a similar 
way to IPv4 proxy-arp.


I'm presume cooperating routers would have to maintain a translation 
table of MAC address to /64 prefix per host wireless interface.


What's the practical difference with moving a /64 (which still 
requires routing changes AFAICS) compared to moving a /128 host route?


None, apart from that a host seldom has a single /128 but instead 
several /128:s. The biggest upside is that you don't need to do DAD 
handling between participating wifi routers (since the host is alone 
in the /64, there is no need to do inter-router DAD).


--
regards,
RayH
<https://www.postbox-inc.com/?utm_source=email_medium=siglink_campaign=reach>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] New Version Notification for draft-barth-homenet-wifi-roaming-00.txt

[Ray Hunter (v6ops)]

Mikael Abrahamsson <mailto:swm...@swm.pp.se>
30 Nov 2015 08:33
On Fri, 27 Nov 2015, Ray Hunter (v6ops) wrote:


How would you "move a /64 around"?


Well, the same way you would move a /128 around I guess.


Not sure that's correct.

When moving a /64 per host you have to presume a /64 has been allocated 
to a host already.


So every time a new host joined wifi you'd have to re-run the entire 
HNCP prefix allocation algorithm AFAICS, and check whether there's a 
conflict of this /64 still being active elsewhere. Unless of course you 
pre-allocate a pool in advance assuming there'll be a certain number of 
hosts on wifi.


On the other hand, for moving individual hosts, I've used a CIDR trick 
in the past when moving data centres that 2 or more LANs are configured 
with an identical IPv4 prefix, and then I've added host routes + proxy 
ARP to trick hosts into thinking they're actually directly connected. 
Should also work for IPv6 as long as CIDR is truly 128 bits (RFC7608).


So it seems to me the missing pieces of the puzzle could be:

1. Identifying cooperating router interfaces across the Homenet and 
assigning a common /64 to them in prefix allocation
2. Maintaining a list of /128 wifi hosts bound to the cooperating 
routers interfaces [including MAC address].
3. detecting "side changes" (in bridge speak) where a host has changed 
connection point and packets are arriving on a new cooperating 
interface. Could potentially be detected when receiving a DAD for a /128 
from the list of wifi hosts with identical MAC address to one previously 
observed.
4. injecting and removing /128 routes as hosts move between cooperating 
interfaces, and updating with list of /128 wifi hosts.
5. Proxy ND equivalent to proxy ARP to answer ND requests on cooperating 
router "local" interfaces for hosts connected to "remote" interfaces.


Proxy ND would include DAD [defending a request for a /128 on a 
cooperating interface with a MAC address not included in the list of 
/128 wifi hosts], but also answering standard ND queries AFAICS so that 
wi-fi connected hosts could inter-communicate. Answers to standard 
queries could be triggered by the presence of a /128 route in a similar 
way to IPv4 proxy-arp.


I'm presume cooperating routers would have to maintain a translation 
table of MAC address to /64 prefix per host wireless interface.


What's the practical difference with moving a /64 (which still 
requires routing changes AFAICS) compared to moving a /128 host route?


None, apart from that a host seldom has a single /128 but instead 
several /128:s. The biggest upside is that you don't need to do DAD 
handling between participating wifi routers (since the host is alone 
in the /64, there is no need to do inter-router DAD).


--
regards,
RayH
<https://www.postbox-inc.com/?utm_source=email_medium=siglink_campaign=reach>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] New Version Notification for draft-barth-homenet-wifi-roaming-00.txt

[Ray Hunter (v6ops)]

Mikael Abrahamsson <mailto:swm...@swm.pp.se>
26 Nov 2015 16:15
On Thu, 26 Nov 2015, Ray Hunter (v6ops) wrote:


I have read this draft and find it interesting.

The use of host routes would seem appealing to avoid
1) any need for stateful "home agent" and multiple forwarding
2) renumbering of the end nodes when roaming
3) relatively small number of hosts compared to the complexity of the 
topology


Use of RFC7217 addresses would seem appropriate, but that assumes 
that DAD really is reliable at the time a node attaches to the 
homenet for the first time.


Wouldn't it be better to adopt 
https://tools.ietf.org/html/draft-ietf-v6ops-host-addr-availability-02 
and just give every device its own /64 and move that around?


Having a full /64 would seem attractive (for maintaining outbound 
sessions on temporary addresses etc.)


How would you "move a /64 around"?

I'm presume cooperating routers would have to maintain a translation 
table of MAC address to /64 prefix per host wireless interface.


What's the practical difference with moving a /64 (which still requires 
routing changes AFAICS) compared to moving a /128 host route?


What's the practical difference in the trigger for executing the move 
(ND neighbor table update, as opposed to a MAC being detected as having 
changed attachment point)?
My worry about the whole L3 approach is how long does it take to 
re-establish packet flows after the L2 wifi handover between APs 
compared to an L2 only solution?


What's the benefit/downside of this approach compared to having 
roaming nodes actively take part in the HNCP acting as "multi-homed 
routers" with an internal (invariant) /64 VLAN used to bind to 
applications?


I'd say this approach adds one more layer that needs to come up before 
packets can start flowing again, especially since it would require 
routing protocol participation as well, I'd imagine.


If 802.11 can assure L2 handover in 1 second (I don't know how long 
the handover time is, just guessing), how much are we willing to add 
in time because of L3 mechanisms added on top of this, before packet 
flows are up and running again?


--
regards,
RayH
<https://www.postbox-inc.com/?utm_source=email_medium=siglink_campaign=reach>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] New Version Notification for draft-barth-homenet-wifi-roaming-00.txt

[Ray Hunter (v6ops)]

Alexandre Petrescu wrote:

Hi,

Using host-based routes in a homenet to support mobility (rather than 
Mobile IP) may make sense because the domain is relatively small.


The draft could benefit from illustrating at least a simple topology, 
to understand what the author really means, because there are very 
many possible topologies to talk about.


Alex

Le 16/10/2015 13:36, Steven Barth a écrit :

Hi everyone,

here is some attempt to formalize a simple WiFi roaming approach
using host routes and a stateless proxy for DAD NDP messages.

It's a bit theoretical right now but may be useful as a start for a
discussion. We could do a talk on it in Yokohama as well.



Cheers,

Steven


On 16.10.2015 13:32, internet-dra...@ietf.org wrote:

A new version of I-D, draft-barth-homenet-wifi-roaming-00.txt
has been successfully submitted by Steven Barth and posted to the
IETF repository.

Name:draft-barth-homenet-wifi-roaming
Revision:00
Title:Home Network WiFi Roaming
Document date:2015-10-16
Group:Individual Submission
Pages:7
URL:
https://www.ietf.org/internet-drafts/draft-barth-homenet-wifi-roaming-00.txt 

Status: 
https://datatracker.ietf.org/doc/draft-barth-homenet-wifi-roaming/
Htmlized:   
https://tools.ietf.org/html/draft-barth-homenet-wifi-roaming-00



Abstract:
This document describes a mechanism to manage host routes and
statelessly proxy IPv6 Duplicate Address Detection messages between
multiple WiFi links to allow client roaming.




Please note that it may take a couple of minutes from the time of 
submission

until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


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






I have read this draft and find it interesting.

The use of host routes would seem appealing to avoid
1) any need for stateful "home agent" and multiple forwarding
2) renumbering of the end nodes when roaming
3) relatively small number of hosts compared to the complexity of the 
topology


Use of RFC7217 addresses would seem appropriate, but that assumes that 
DAD really is reliable at the time a node attaches to the homenet for 
the first time.


What happens if a homenet becomes temporarily "split-brain" and then 
remerges?

Isn't there a danger of two nodes acquiring the same address.
What happens then? (as DAD has already completed on both client nodes)

What's the mechanism/timing of ND expiry compared to WIFI roaming and 
distribution of route updates?

Isn't this going to be "too slow"?
Should the routers be performing an active "keep alive" on locally 
attached nodes?

[not good for battery life on wireless]

What about using an explicit registration, with each homenet router 
acting as a 6LBR?
e.g. RFC6775 ND Optimization for 6LoWPANs, as the registration 
mechanism, which is then used to inject the host route.


What's the benefit/downside of this approach compared to having roaming 
nodes actively take part in the HNCP acting as "multi-homed routers" 
with an internal (invariant) /64 VLAN used to bind to applications?


--
regards,
RayH

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

Re: [homenet] WiFi handover [was: question: equal-cost multipath?]

[Ray Hunter (v6ops)]

Alexandru Petrescu <mailto:alexandru.petre...@gmail.com>
2 Sep 2015 11:31


Le 01/09/2015 18:06, Ray Hunter a écrit :

inline

Alexandru Petrescu wrote:



Le 12/08/2015 14:20, Eric Vyncke (evyncke) a écrit :




While I pay for it, I never use the millions of WiFi access points I
can
use here in the Netherlands. I tried it once, walking in a small
city. At
the time the handover was completed, the connectivity was gone.


This is a question of use-cases.  In a city yes there are many
hotspots but also yes they're sparsely distributed - you must handover
to something else in between.  In a home network they'd be densely
distributed, could hand-over directly, or not at all.

Actually they're pretty densely distributed around me.

There's one AP per household (via the cable TV provider) which has an
SSID for dedicated use.

These also support the guest/roaming access using a common SSID
identical on all APs.


YEs.


There are 5 apartments within wifi range of my desktop (I can see that
via the dedicated SSID).
And I find 12 on my mobile if I walk to the balcony.


I can agree.   I guess while the beacons are seen strong, once 
connected the strength becomes lower for some reason.


Also, automatic handing-over to such apparently dense hotspots is 
hampered on-purpose by administrative will: security keys, captive 
portals, acceptance conditions, and more.


It's a problem in home networks and also while travelling: airport, 
hotel, restaurant networks.


I am not sure how to relate this precisely to homenet WG...

Alex

Homenet has created multiple L3 routed wifi networks.

I think we'll probably have to wait for DMM to nail down thier potnetial 
solutions before drawing firm conclusions. There's not a lot of specific 
information in the DMM WG documents I read so far, as it's early days.


But I think it's fair to conclude that there'll be some interaction with 
/extension of HNCP required (for selecting and configuring IP anchors 
and SSIDs).






You could be moving a lot and never handing over, as much as you could
sit and do many hand-overs per second.

Such use-cases and reqs are described in DMM WG documents.


ACK


Alex

 It might

have to do with IEEE and IETF mismatch. Same SSID shall have same IP
subnet (IEEE) versus each link has its own subnet (some of IETF, no
formal statement...).


Of course, if every SSID has its own 192.168.0.0/24, oups, this is
legacy
IP, so, not a Homenet topic :-O

Sorry could not resist

-éric

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










--
regards,
RayH
<https://www.postbox-inc.com/?utm_source=email_medium=siglink_campaign=reach>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Host naming in Homenet

[Ray Hunter (v6ops)]

Michael Thomas wrote:



On 08/31/2015 04:42 AM, Ray Hunter (v6ops) wrote:


Juliusz (and others) have objected to 
https://tools.ietf.org/html/draft-ietf-homenet-naming-architecture-dhc-options 
because it appears to be tied to the ISP. Yet for reverse resolution, 
the ISP is an essential party, because they have been delegated the 
DNS zone for their entire allocated address space. And Homenet uses 
delegated prefixes from within this overall allocation.


What that tells me, on the other hand, is that these are two separate 
problems that
just need to get solved. And, in fact, the forward and reverse maps 
may not same auth/authz

requirements for their respective CRUD operations.

Mike

I think you may be right, assuming we want to do DNS for Homenet properly.

i.e. we should be talking about updating multiple ISPs for reserve 
resolution (per delegated IPv6 prefix), and potentially multiple ISPs or 
independent DNS providers for forward resolution (per delegated name space).


And when we're talking about "updating" we also have at least two 
alternatives:
1) maintaining the RRs in the ISPs' or 3rd party DNS providers' DNS 
servers, or
2) ensuring proper delegation and glue records exist, pointing at 
Homenet's own DNS servers (whether they are located on or off Homenet).


Automating zone delegation and glue record insertion with zeroconf seems 
quite a hole in current standards.

and that is also not covered in DNS-SD AFAICS.


--
regards,
RayH
<https://www.postbox-inc.com/?utm_source=email_medium=siglink_campaign=reach>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Host naming in Homenet

[Ray Hunter (v6ops)]

STARK, BARBARA H 
1 Sep 2015 12:23
and that is also not covered in DNS-SD AFAICS.


As a potential end user of homenet (i.e., within my personal home 
network), I very much do *not* want any of my IoT devices, printers, 
or scanners to be publicly discoverable via DNS. If and when I want 
anything discoverable via public DNS, I want to be very explicit about 
what that is. So any "automating zone delegation" solution needs to 
have as a requirement that it must not automatically cause anything to 
be externally discoverable that the end user does not explicitly identify.


The tremendous lack of security being built into printers, scanners, 
IoT devices, and other devices on the home network suggest that 
automatically exposing them to external discovery would likely have 
Very Bad Consequences for the majority of end users (who will be 
completely unaware that such automatic exposure was occurring).

Barbara


I hear you.

But I think the discussion on automatic delegation of a DNS name space 
is separate from which content Homenet publishes in which zone.


I'm thinking of a delegation mechanism similar to how RFC3633 delegates 
address prefixes, that would allow a DNS service provider to delegate 
one or more subsets of their name space to a Homenet to use as it's 
parent name space.


The transport for this delegation mechanism might be DHCPv6, for the 
case where a DNS operator (the ISP) wants to delegate a reverse zone for 
PTR records for reverse resolution, but it might also be an API over 
HTTP for where there's a DNS provider who has no business relationship 
with the upstream ISP(s). Or both


The name space delegation would support the use case where the DNS 
service provider supplies information for the Homenet on how to update 
the RR hosted on the DNS provider's DNS servers, as well as the use case 
where the Homenet itself provides the DNS servers, and the DNS service 
provider has to enter NS records and glue records in their own DNS servers.


Once those name space delegations are in place, it would be a separate 
discussion on how content is generated and updated e.g. printers using 
ULA addresses should not be pushed to a zone visible on the public Internet.


If we don't have a set of unique parents for the Homenet name space 
(either delegated or self-generated), we'll also run into security 
issues, as .home or .local themselves are not unique for devices that 
roam between multiple (disjoint) Homenets. In exactly the same way that 
ULA addresses also have to be (reasonably) unique across the set of 
Homenets.


So myprintservice..home. would be fine for me for the ULA 
space. The  portion of the name space would obviously not 
generally be displayed to end users.


And for GUA space it could be myservice..myisp.com 
or myservice..mydnsservice.org



--
regards,
RayH

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

Re: [homenet] WiFi handover [was: question: equal-cost multipath?]

[Ray Hunter]

inline

Alexandru Petrescu wrote:



Le 12/08/2015 14:20, Eric Vyncke (evyncke) a écrit :




While I pay for it, I never use the millions of WiFi access points I 
can
use here in the Netherlands. I tried it once, walking in a small 
city. At

the time the handover was completed, the connectivity was gone.


This is a question of use-cases.  In a city yes there are many 
hotspots but also yes they're sparsely distributed - you must handover 
to something else in between.  In a home network they'd be densely 
distributed, could hand-over directly, or not at all.

Actually they're pretty densely distributed around me.

There's one AP per household (via the cable TV provider) which has an 
SSID for dedicated use.


These also support the guest/roaming access using a common SSID 
identical on all APs.


There are 5 apartments within wifi range of my desktop (I can see that 
via the dedicated SSID).

And I find 12 on my mobile if I walk to the balcony.



You could be moving a lot and never handing over, as much as you could 
sit and do many hand-overs per second.


Such use-cases and reqs are described in DMM WG documents.


ACK


Alex

 It might

have to do with IEEE and IETF mismatch. Same SSID shall have same IP
subnet (IEEE) versus each link has its own subnet (some of IETF, no
formal statement...).


Of course, if every SSID has its own 192.168.0.0/24, oups, this is 
legacy

IP, so, not a Homenet topic :-O

Sorry could not resist

-éric

___
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] Host naming in Homenet

[Ray Hunter (v6ops)]

Erik Kline wrote:

On 26 August 2015 at 15:41, Juliusz Chroboczek
  wrote:

Can we just go with whichever recommendations come out of dnssd?

 https://datatracker.ietf.org/wg/dnssd/charter/
 https://datatracker.ietf.org/wg/dnssd/documents/

Could you perhaps point me at a specific paragraph of a specific draft and
tell me "Do implement this, we're betting the company on this protocol"?


No, I cannot...not at this time.  But solving the homenet case is a
requirement, and documented in https://tools.ietf.org/html/rfc7558
(section 3, use case "C", I believe).


I am familiar with Appletalk Phase 2, so the concepts in DNS-SD come as 
no surprise.


However, AFAICS after reading the DNS_SD documents including 
https://tools.ietf.org/html/rfc7558, I think I detect one hole for Homenet.


Although there's a requirement for topology independent zones and 
autoconfig, it's a bit opaque to me:


1) if overlapping zones/namespaces are allowed (multiple ISPs with 
potentially multiple parent delegated name spaces).
That was not allowed in Appletalk Phase 2, and the zones were configured 
manually by an administrator.


2) How the parent namespace(s) are delegated (using zeroconf).

We already have https://tools.ietf.org/html/rfc3633 for explicitly 
delegating address prefixes.


But there doesn't seem yet to be any appetite for a standard mechanism 
for delegating namespaces (e.g. via DHCPv6).


Juliusz (and others) have objected to 
https://tools.ietf.org/html/draft-ietf-homenet-naming-architecture-dhc-options 
because it appears to be tied to the ISP. Yet for reverse resolution, 
the ISP is an essential party, because they have been delegated the DNS 
zone for their entire allocated address space. And Homenet uses 
delegated prefixes from within this overall allocation.


Also DND SD (RFC 6763) states "Address-based Domain Enumeration queries 
are performed using names under the IPv6 reverse-mapping tree" which is 
under the direct control of the individual upstream ISPs.


So, what are people expecting to happen here?
ISP's to cooperate with independent name services when sending a DHCPv6 
delegation of a namespace e.g. a party like DYNDNS? So the Homenet 
learns everything via one neatly packaged DHCPv6 exchange with each 
upstream provider?

Multiple upstream DNS services that need to be updated?
Overlapping namespaces?
Multiple namespace delegation via multiple mechanisms? e.g. Homenet 
learns the reverse tree from the upstream ISP (via DHCPv6), and forward 
delegation (glue records) are entered via the domain registrar via http 
or something else?


In IPv4 I have my own private company domain bootstrapped by my own 
(manually added  glue records) from my own Domain Registrar (100% 
independent of my ISP). And the ISP adds dummy static reverse records 
and A records, so triple resolution works.


Is this what we want for IPv6, or do we have to deal with seeding 
information into multiple upstream DNS's?


Permitting inbound services and restoring the end to end architecture of 
the Internet is a big part of Homenet IMVHO


--
regards,
RayH

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

Re: [homenet] Host naming in Homenet

[Ray Hunter]

Markus Stenberg wrote:

On 26.8.2015, at 16.17, Juliusz Chroboczekj...@pps.univ-paris-diderot.fr  
wrote:

I guess we might as well simply recommend MDNS

Fair enough, assuming there is mDNS proxying in the Homenet.  (Or should
we be speaking on ff05::fb and counting on Pierre to do some magic?)


It is not really an option - it requires serious host changes.

Of course, if you’re completely crazy you could do some sort of linklocal -  
sitelocal -  linklocal translation, but I would rather not go there especially as 
you would want to eliminate e.g. linklocal addresses from A/ records =conflict 
resolution breaks =  oops.

The options in increasing level of evil from my point of view are:

- DHCPv6 (ha ha! but at least it is simple in this case)
- hybrid proxy (rather complex but works)
- mdns-to-mdns proxying (complex, fragile, easy to break)

Cheers,

-Markus
IMHO This is a very worthwhile discussion that we've glossed over for a 
long time.


I've seen several drafts over the course of the Homenet WG.

e.g. 
https://tools.ietf.org/html/draft-ietf-homenet-front-end-naming-delegation-03 
discusses how DNS can be bootstrapped and parent domains delegated to a 
Homenet Border Router.


So that seems to be one portion of the overall jigsaw.

And 
https://tools.ietf.org/id/draft-jeong-homenet-device-name-autoconf-03.txt talks 
about each device auto-naming then the router performing discovery using 
NI [RFC4620] coupled with dynamic update [RFC2136] to seed LLN devices 
into the (global) DNS.


We also have https://datatracker.ietf.org/doc/rfc7558/?include_text=1 
that details requirements for extending mDNS e.g. linking mDNS 
sub-domains of the parent namespace to physical interfaces.


Meanwhile windows in the enterprise generally uses a delegated portion 
of the overall DNS namespace such as win.company.com and it's own update 
mechanisms internally.


So what are the expectations/requirements for naming in Homenet, and 
particularly host - router interaction?


How will name registration work?
Are we looking at a single flat name space?
How will name conflicts be resolved?
Are we looking at a name space that is link dependent?
Are we looking at a name space that includes delegations via subdomains 
for special devices or technologies?
Are we looking at supporting nodes that roam from link to link often 
within the Homenet?
What about devices that couple and uncouple from the Homenet? (mobile 
phones with wifi and 3G)
Is this going to turn into (another) DNS/mDNS war, or is there a model 
in which the two can peacefully co-exist?

e.g. query mDNS first? query both simultaneously?
e.g. seed mDNS into a DNS delegated domain?
e.g. translate mDNS queries into DNS and perhaps vice versa?

How will resolution work?
Will the end host be responsible for performing multiple resolution? Or 
the Homenet router?
Are we looking at electing a single authoritative DNS server for all of 
Homenet? With standby?

Or one DNS server per Homenet Border Router?
Or is every Homenet device a DNS/name server and we deploy a (large) 
search list.


Perhaps most importantly: What mechanisms do common host operating 
systems support today?


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

Re: [homenet] question: equal-cost multipath?

[Ray Hunter]

Alia Atlas wrote:
I am interested to learn what people think about whether equal-cost 
multi-path routes are needed in homenet.  Given the previous 
discussion about parallel wireless links - which I know I have in my 
house and can't use - I've been wondering if these have been considered.


ECMP is critical in the data-center and backbone, but I'm interested 
in seeing what the reasoning is as to why it isn't or is needed in the 
homenet scenarios.


Thanks,
Alia

P.S. I do expect that any routing protocol can be made to do ECMP, of 
course.


I was surprised ECMP did NOT work when I tested the latest homenet code. 
All the elements are capable of doing it, but it wasn't implemented.


One reason IMHO that it's potentially useful (but not essential) is that 
(most) plastic homenet routers include a L2 switch in front of the L3 
interface(s). Therefore the L2 interface doesn't actually physically go 
down when cables are unplugged/ links are unstable. Without ECMP you get 
many seconds of complete black holing whilst the router figures out at 
L3 (RP hellos or HNCP) that the interface is actually down and the 
neighbour has gone away. With ECMP you just get bad packet loss if load 
balancing is per packet.


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

Re: [homenet] WiFi handover [was: question: equal-cost multipath?]

[Ray Hunter]

Teco Boot wrote:

Op 12 aug. 2015, om 12:27 heeft Juliusz 
Chroboczekj...@pps.univ-paris-diderot.fr  het volgende geschreven:


I still think the Homenet WG should pay far more attention to seamless
WiFi handover,

We're currently working on that with the WLAN-SI guys.  They've got
a nationwide mesh network (it's a small country, granted, and they use the
public Internet infrastructure whenever possible), and while they're not
interested in roaming at a global scale, they insist on seamless roaming
within a small cluster of routers (home or village sized), and they insist
on no host changes and good support for Android hosts.


Great!


+1

We'll write to this list when we know what works.


Boring. I'm interested in what doesn't work :-)

While I pay for it, I never use the millions of WiFi access points I can use 
here in the Netherlands. I tried it once, walking in a small city. At the time 
the handover was completed, the connectivity was gone. It might have to do with 
IEEE and IETF mismatch. Same SSID shall have same IP subnet (IEEE) versus each 
link has its own subnet (some of IETF, no formal statement...).

Teco
I second this end-user experience: 2 million access points in one of the 
most densely populated areas on Earth, very strong signal coverage, but 
a pretty useless experience because handoff is so poor.


End host modifications aren't in Homenet scope, but wifi roaming is 
something we really need to address (to at least clarify what Homenet 
will/ will not support in terms of SSID etc. )



In case it doesn't show, I'm enthusiastic about the energy and competence
of the WLAN-SI core team.  They make a serious effort in translating
everything they do into English, and they've got a nice node database
online (even nicer one ready, but not deployed yet):

  https://wlan-si.net/
  https://nodes.wlan-si.net/

-- Juliusz



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

Re: [homenet] Moving forward.

[Ray Hunter]

Mikael Abrahamsson mailto:swm...@swm.pp.se

5 August 2015 08:50
On Tue, 4 Aug 2015, Ray Hunter wrote:

As someone who spent rather a lot of time wordsmithing Section 3.5 of 
RFC7368 into something that could reach rough consensus, I find this 
discussion rather depressing. Section 3.5 was the list of 
requirements we could agree on when the architecture document 
shipped. I've been on record as being agnosting in the choice of 
routing protocol, and hope(d) the DT would deliver us from stalemate, 
so I remained silent.


We have been trying to address all objections to ISIS by addressing 
the few things that were not already there. Yet, people keep arguing.


I'm not arguing against IS IS. But I think the IS IS proponents have 
singularly failed to clearly express what is proposed for Homenet.


To my mind that has now been largely corrected with

https://tools.ietf.org/html/draft-lamparter-homenet-isis-profile-00

Although there are an awful lot of current ID drafts in the must 
implement list.


And there are still gaps e.g. How to set metrics. How to handle security.

Now I see a lot of super-heavyweight industry names seemingly failing 
to grok Homenet in general, and specifically the use case of WIFI as 
a home backbone.


What makes you say this, especially in light of what was presented at 
the last IETF?

This thread.


But if we go for IS IS we're apparently going to have to wait 
(perhaps forever) to get L3 routing over WIFI working/ stable. 
Something that we've pointedly failed to do in professionally managed 
office networks in the last 20 years.


Again, what makes you say this?


Ted's mail of Sat, 25 Jul 2015 21:07:43 -0400


I keep hearing that babel is loop free and that this is a great 
feature. My take on that is that it's a great feature when wifi just 
sucks and keep going bad and keeps going away and coming back, and 
you're happy if a few packets are delivered once every now and then. 
When I say this, Juliuz says I am silly.


I make sure my wifi works 99.9% or more of the time. Unless it always 
works, it's useless to me. I don't see why isis+wifi-backbone couldn't 
be used in my home (not that I will do that, but if I would).


So again, with basic features like setting the metric depending on 
interface speed and type (which has been around for 15-20 years for 
routing protocols in all kinds of places), what is it that babel would 
actually give us in a decently working homenet with wifi backbone?


ISIS will handle just fine when people unplug and plug cables back in. 
Field engineers have been doing this (badly) forever, ever since 
people started doing computer networking.


I'm not talking about cables. I've run serious IS IS backbone networks 
(together with MPLS). I know what IS IS can do in that sort of 
environment. It's a great protocol.
I will yield that babel is better in a mesh network where all bets are 
off, but is that really the kind of network we expect people to have? 
The Internet is moving towards supporting real time communication that 
must always work. Yet, I keep hearing that this isn't the homenet 
we're expecting to have? Or what am I missing?



The Internet is also going wireless.
On the flip side I don't see barriers to Babel running on small 
cabled networks.


I keep hearing this. As far as I know, nobody has ever said babel 
wouldn't run on cabled networks. I don't see why this point is 
repeated, nobody is arguing with this point.
Because Babel seems to do what IS IS can, plus more. If that's not the 
case, then I'd like to see how IS IS can run in lossy and mesh networks.


In short: I largely agree with Ted, but I see the WIFI backbone use 
case as a killer differentiator for Homenet (regardless of the final 
choice of routing protocol). If IS IS can't deliver on that, then 
it's a real miss.


It can.

I guess this is a show me moment.

Where can I download the code to test on Openwrt?

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

Re: [homenet] some IS-IS questions

[Ray Hunter]

Markus Stenberg wrote:

On 29.7.2015, at 17.35, STARK, BARBARA Hbs7...@att.com  wrote:

Perfect! Thanks. I'd missed that. Yes, that's exactly what I was looking for.



So when the Design Team compares IS-IS to Babel, they really should be 
comparinghttps://tools.ietf.org/html/draft-lamparter-homenet-isis-profile-00 to 
RFC6126+RFC7557+draft-boutier-babel-source-specific-01.

Well said.



Any other IS-IS comparison would involve a hypothetical IS-IS. Since a 
hypothetical IS-IS, by definition, does not exist, a hypothetical IS-IS would 
fail thecriterion that requires examination only of existing IGPs.


First of all, thanks from me to David L. as well for the document; I love 
having it around.

I think the metric stuff is missing from that at least (although they are 
'wide' which helps I guess to express 10 better); so we're dealing with fixed 
default metric IS-IS configuration here.
Yes, but it's still not nailed down. The architecture requires support 
for heterogeneous link layers. IMHO That means metrics have to take 
into account link type, if not measured reliability. Pure hop count 
won't cut it for Homenet. And default metrics on most IS IS 
implementations I know default to hop count behaviour (metric of 10 per 
interface crossed).


It seems to be also missing security.

Yes.

And to echo Barbara, if that is not the plan, now would be good time to update 
the document.

+1

Cheers,

-Markus

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

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

[Ray Hunter]

Daniel Migault wrote:

Hi,

I believe draft-ietf-homenet-front-end-naming-delegation [1] , 
draft-ietf-homenet-naming-architecture-dhc-options [2] have addressed all 
comments we received so far. I believe these document are ready.

draft-ietf-homenet-front-end-naming-delegation-02 addresses the renumbering 
issue and added significant text in the security considerations section. So, 
please have a look these sections.

draft-ietf-homenet-naming-architecture-dhc-options-02.txt. The only changes 
from the previous version is the replacement of master/slave by 
primary/secondary.

Feel free to provide feed backs!
BR,
Daniel

[1] 
https://tools.ietf.org/html/draft-ietf-homenet-front-end-naming-delegation-02
[2] 
https://tools.ietf.org/html/draft-ietf-homenet-naming-architecture-dhc-options-02

-Original Message-
From: homenet [mailto:homenet-boun...@ietf.org] On Behalf Of 
internet-dra...@ietf.org
Sent: Tuesday, May 19, 2015 11:59 AM
To: i-d-annou...@ietf.org
Cc: homenet@ietf.org
Subject: [homenet] I-D Action: 
draft-ietf-homenet-naming-architecture-dhc-options-02.txt


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

 Title   : DHCP Options for Homenet Naming Architecture
 Authors : Daniel Migault
   Wouter Cloetens
   Chris Griffiths
   Ralf Weber
Filename: 
draft-ietf-homenet-naming-architecture-dhc-options-02.txt
Pages   : 28
Date: 2015-05-19

Abstract:
CPEs are usually constraint devices with reduced network and CPU
capacities.  As such, a CPE hosting on the Internet the authoritative
naming service for its home network may become vulnerable to resource
exhaustion attacks.  One way to avoid exposing CPE is to outsource
the authoritative service to a third party.  This third party can be
the ISP or any other independent third party.

Outsourcing the authoritative naming service to a third party
requires setting up an architecture which may be unappropriated for
most end users.  To leverage this issue, this document proposes DHCP
Options so any agnostic CPE can automatically proceed to the
appropriated configuration and outsource the authoritative naming
service for the home network.  This document shows that in most
cases, these DHCP Options make outsourcing to a third party (be it
the ISP or any ISP independent service provider) transparent for the
end user.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-homenet-naming-architecture-dhc-options/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-homenet-naming-architecture-dhc-options-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=aft-ietf-homenet-naming-architecture-dhc-options-02


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

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

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



I have just read through 
https://tools.ietf.org/html/draft-ietf-homenet-naming-architecture-dhc-options-02 
again


Generally, it is looking pretty good.

A couple of comments:

1. The use of the name Security Field in section 6.1 this draft is 
rather unfortunate IMHO.


Humbly suggest Supported Authentication Methods? [to match terminology 
in 
https://tools.ietf.org/html/draft-ietf-homenet-front-end-naming-delegation-02 
]


Plus s/Security/Supported Authentication Methods/g in other sections.

2. I miss more detailed discussion in Section 7.1 about when/if a server 
should accept an update of the public key record from a CPE.


Section 9.2 notes this problem but doesn't address the problem further.

Section 9.2 should also probably note:
The initial update of the public key between the CPE to the ISP 
infrastructure is fundamental to the security of the entire name 
delegation process. If an attacker can subvert the initial public key 
update, then all further security and encryption mechanisms may also be 
subverted.


Shouldn't section 9.2 of the draft  It is therefore RECOMMENDED to use 
the Authentication Option as specified in Section 22.11 of RFC3315


I realise that there are conflicting requirements between zeroconf and 
knowing precisely which CPE is related to which customer.


3. Is there a need here for potentially further 
authentication/validation of the public key update option itself?


A number of mechanisms come to mind for consideration:
- no additional security
- server enforces a strong coupling between DHCP DUID - CPE 

Re: [homenet] Selecting a routing protocol for HOMENET

[Ray Hunter]

Ralph Droms wrote:

On Apr 7, 2015, at 6:47 AM 4/7/15, Juliusz 
Chroboczekj...@pps.univ-paris-diderot.fr  wrote:


The DT will be chartered as below.

I find the lack of the words working code, implementation experience
or experimental data somewhat disquieting.
+1 I'd like to see a DT with hands on experience of running Homenet code 
before IETF 93 in Prague, and that they give this appropriate weight in 
any considerations.

I think the umbrella direction for requirements could be considered to cover 
those specifics:


For the design team to make this determination, it shall first
understand the use-cases for homenet and derive routing requirements
from those.


Terry - you might consider adding a pointer to RFC 7368 as an explicit source 
of input for the requirements.
+1 The WG achieved rough consensus on Section 3.5 of RFC 7368. That 
should be the baseline for any beauty contest of routing protocols for 
Homenet.



- Ralph


With frustrated regards,

-- Juliusz Chroboczek

___
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] Fwd: I-D Action: draft-ietf-homenet-naming-architecture-dhc-options-01.txt

[Ray Hunter]

Apologies for the very late reply: change weekends.


Daniel Migault mailto:mglt.i...@gmail.com
20 March 2015 20:55
Hi Ray,

Please see my comments in text.

I think the description of the requirements and overall chain of
events is excellent. Thanks for that.

However I'm not particularly convinced by the security and
authentication mechanisms, as the proposed text just seems to punt
these to another transport protocol.

Thank you for raising this point, but this is not the case. I need to 
make the text clearer. When a renumbering occurs, the Hidden Master 
changes its IP address, and has to provide the new IP address to the 
slave. This can be done with DNS extensions or other layers. I will 
update the section 9.1.2 to clarify this.

Cool. Thanks.



I also don't see the recovery mechanism/ how to distinguish
between a break before make event, and a make before break where
the ISP's DNS servers may not be reachable at the moment of
renumbering, or that a Homenet is simply not reachable for some
time, and comes up unnumbered with no old IP, or that the
Homenet never comes back at all. It seems to me that you could
also end up hosting lots of cruft in the ISP servers, and there's
a need for some garbage collection.

I am not sure I correctly get the use case:
a) It seems to me you consider also the case where the slave is 
being renumbered. I did not considered this point and assume these 
servers will hardly renumbered.

To be honest this should be a corner case.

But it would be nice if the slave was also discovered via a DNS records 
rather, than a literal, or cached IPv6 address.
b) It also seems to me you consider a Homenet work that is removed 
or not in used, and you wonder what happen to the zone? My 
understanding is that it is similar a service you subscribed and you 
do not use. Do you mean that we should state that after some time, the 
slave may remove its zone?



Correct. It would be cruft removal.
Can you please elaborate on the use cases you think we should comment? 
Is sounds to me these considerations may not be related to 
renumbering, but instead to general operations.

They are indeed more general cases of changes.


I also expect we need some more limitations on when/why a slave
would poll an unknown hidden master, otherwise it seems to me that
we have a nice DoS vector/ amplification attack. A number of
attack machines could spoof notification messages pointing to
various ISP slave systems, all pointing to a common target victim
new hidden master.


This is mentioned in the NOTIFY RFC1996 in the security consideration. 
A forged NOTIFY results makes the slave trigger a SOA query. These are 
small paquets, thus the amplification factor is very small. RFC1996 
qualify it as a begnin DoS attack. But I agree I will comment on that. 
Actually I though of writing a specific section on it. That will be 
done in the next version anyway.


If we are not specifying the mechanism more precisely, then there should 
be some warning that the slave should only try once to reach the new 
hidden master for every incoming notify request. Ant retries should be 
triggered from the hidden master sending a new NOTIFY request, not the 
slave retrying independently.  Otherwise you really are creating an 
amplification attack.



It feels to me like
1) we need a more reliable update mechanism between the hidden
master and the slaves (to cover longer-term unreachability events,
or a Homenet hidden master going off air permanently)
2) we need a more effective authentication mechanism for
triggering updates, that is source IP address agnostic.

This is the case, as authentication is based only cryptographic keys. 
The IP address is only used for reach-ability and is never used 
otherwise.



-- 
Regards,

RayH




--
Daniel Migault
Ericsson


--
Daniel Migault
Ericsson
___
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

[Ray Hunter]

Daniel Migault mailto:mglt.i...@gmail.com
16 March 2015 02:48
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.


Feel free to make any comment.

BR,
Daniel

9 Renumbering

This section details how the CPE is expected to handle renumbering. 
Renumbering has been extensively described in RFC4192 and analyzed in 
RFC7010. This section is largely inspired by these document, and the 
reader is expected to become familiar with them.


This section considers two ways to renumber the home network:
- make-before-break: In this scenario, the new prefix is 
advertised, the network is configured to prepare the transition to the 
new prefix. During a period of time, the two prefixes old and new 
coexist, before the old prefix is completely removed.
- break-before-make: In this scenario, the new prefix is 
advertised making the old prefix obsolete.


The make-before-break scenario is recommended, but this section 
details both.


In both scenarios, this section is focused on how renumbering affects 
the DNS(SEC) Homenet Zone and how renumbering affects the 
communication between the Hidden Master and the slave hosted on the 
Public Authoritative Name Server Set. This section designates by 
OLD_PREFIX and OLD_IP the IP prefix and IP addresses that are to be 
replaced and NEW_PREFIX and the NEW_IP the replacing IP prefix and IP 
addresses.


The initial situation is as follows: the CPE has configured its naming 
architecture as depicted in Figure 1 (Section 4.1). More specifically, 
the CPE has set the DNS(SEC) Homenet Zone as detailed in Section 4.2, 
and it is assumed that some hosts are configured with OLD_PREFIX. In 
addition the Hidden Master and the Public Authoritative Name Server 
Set are configured as detailed in Section 5. The Public Authoritative 
Name Server Set is configured as a slave for the Homenet Domain Name. 
The communication between the Hidden Master and the slave uses the 
OLD_IP of the Hidden Master. Usually, the slave is configured with the 
master's IP address. In our case the slave is configured with OLD_IP.


9.1 make-before-break

In the make-before-break renumbering scenario, the CPE is informed 
that renumbering will happen in the future. The CPE waits that routers 
ad switches are ready to route both OLD_PREFIX and OLD_PREFIX on the 
home network. The necessary time for the CPE to be aware of the 
bindings between the hosts of the home network and the NEW_IPs may 
vary, depending on how binding between the NEW_IPs and the various 
hosts in the home network is performed as well as how the CPE is 
informed of the newly assigned IP addresses. After some time, either 
that all hosts have provided their corresponding NEW_IPs or a timer 
has expired, the CPE provides an updated version of the DNS(SEC) 
Homenet Zone to the Hidden Master. As explained in Section 9.1.1, the 
TTLs may also be adjusted.


The updated DNS(SEC) Homenet Zone is then updated on the slave 
using the same configuration as used until now. In fact, there is no 
need to update the master/slave configuration as currently both IP 
addresses of the Hidden Master are reachable (IP_OLD and IP_NEW). This 
process may have been proceed earlier, or may be processed later. Even 
though updating the DNS(SEC) Homenet Zone and updating the IP address 
used by the Hidden Master are completely different processes, they may 
be combined as explained in section 9.1.2. At that time, the DNS(SEC) 
Homenet Zone has been updated with both NEW_IPs and OLD_IPs, the 
DNS(SEC) Homenet Zone is being publicly published on the Public 
Masters, and the master/slave mechanism uses the NEW_IP of the Hidden 
Master.


The final step consists in removing the OLD_IPs of the DNS(SEC) 
Homenet Zone file and updating the zone on the Public Masters. The 
removal of the OLD_IPs RRsets SHOULD be performed such that there is 
no more RRSets contains OLD_IPs in any cache when OLD_PREFIX is not 
reachable anymore. TTLs should be chosen appropriately to meet timing 
constraints as explained in section 9.1.1.


9.1.1 Adjusting TTLs

As TTL designates how long the RRsets are cached, they should be 
adjusted regarding the time both OLD_IP and NEW_IP are reachable and 
the time OLD_IPs are removed from the DNS(SEC) Homenet Zone. Let 
T_OLD_NEW designate the time the DNS(SEC) Homenet Zone contains both 
OLD_IPs and NEW_IPs, and T_NEW the time when OLD_IPs are removed from 
the DNS(SEC) Homenet Zone. Let OLD_TTL the TTL value before T_OLD_NEW, 
OLD_NEW_TTL the TTL value after T_OLD_NEW and NEW_TTL the TTL value 
after T_NEW.


When a RRset is modified, it takes 2*TTL seconds for the previous 
value to be removed from all caches. As a result, it will take 
2*OLD_TTL before the DNS(SEC) Homenet Zone becomes stable have have 
its RRsets containing both OLD_IPs and NEW_IP in all caches. Going to 
a stable state where both OLD_IP and NEW_IP are 

Re: [homenet] I-D Action: draft-ietf-homenet-prefix-assignment-03.txt

[Ray Hunter]

Pierre Pfister mailto:pierre.pfis...@darou.fr
14 March 2015 09:10
Hello Ray,

Thanks for the review.


Their actually is something about that already. Sub-delegation is one 
of the purposes of the so called « Private Links »


Private Link: A Private Link is an abstract concept defined for the
sake of this document. It allows nodes to make assignments for
their private use or delegation. For instance, every DHCPv6-PD
[RFC3633 https://tools.ietf.org/html/rfc3633] client MAY be 
considered as a different Private Link.


Another node, by some mean such as DHCPv6-PD, asks for prefixes. In 
order to provide a prefix, the algorithm may be executed on a Private 
Link representing that client node. It is true that the proxy needs to 
be careful when it provides prefixes this way. Which is why the 
« Apply Timer » exists.


Applied (Assigned Prefix): When an Assigned Prefix is applied, it
MAY be used (e.g., for host configuration, routing protocol
configuration, prefix delegation). When not applied, it MUST NOT
be used for any other purposes than the prefix assignment
algorithm. […]


In order to help moving forward with specifications, the PA draft was 
purged from any purely Homenet specific considerations (Prefix Length 
considerations, Prefix Lifetimes, ULA generation, …). These 
considerations now belong to the hncp document 
(draft-ietf-homenet-hncp-04). Particularly, Recursive Prefix 
Delegation is described in Section 6.2.6 of the HNCP document.



Thanks,

- Pierre




OK Got it. Thanks.

Another question. I've been testing with smaller prefixes than that 
required to configure the Homenet.


Is behavior defined for that situation?

i.e. I am delegating a /60 but I have 9 interfaces (with 4 common) = 6 
prefixes to assign in Homenet.


Theoretically that should fit. And it does

Delegating router gives out a lease for 2001:6d8 :67d2 :1f0::/60

So Homenet 1 has
2001:6d8:67d2:1f9:16cc:20ff:fe8a:15c4/64(common with Homenet 2)
2001:6d8:67d2:1ff:16cc:20ff:fe8a:15c4/64
2001:6d8:1f15:62e:16cc:20ff:fe8a:15c4/64 (WAN)

Homenet 2 has
2001:6d8:67d2:1f9:16cc:20ff:fe8a:15d6/64 (common with Homenet 1)
2001:6d8:67d2:1f5:16cc:20ff:fe8a:15d6/64
2001:6d8:67d2:1f7:16cc:20ff:fe8a:15d6/64 (common with Homenet 3)

Homenet 3 has

2001:6d8 :67d2 :1f7:16cc:20ff:fe8a:154c/64 (common with Homenet 2)
2001:6d8 :67d2 :1f3:16cc:20ff:fe8a:154c/64
2001:6d8 :67d2 :1f2:16cc:20ff:fe8a:154c/64


Now if I reduce the lease to a /62 I get problems (as expected)

lease granted is 2001:6d8 :67d2 :130::/62

2001:6d8 :67d2 :131:b834::89fe/80(common with Homenet 2)
2001:6d8 :67d2 :131:2eb6::9bb2/80
2001:6d8:1f15:62e:16cc:20ff:fe8a:15c4/64 (WAN)

Homenet 2 has
2001:6d8 :67d2 :131:b834::e8a9/80 (common with Homenet 1)
2001:6d8 :67d2 :131:2e46::a68a/80
2001:6d8 :67d2 :130:16cc:20ff:fe8a:15d6/64 (common with Homenet 3)

Homenet 3 (powered on first) has

2001:6d8 :67d2 :132:16cc:20ff:fe8a:154c/64
2001:6d8 :67d2 :133:16cc:20ff:fe8a:154c/64
2001:6d8 :67d2 :130:16cc:20ff:fe8a:154c/64 (common with Homenet 2)


So this looks like a pathological case (as expected).

Is it defined what should happen in this case?

Should a prefix be split, or simply as many /64's as possible be assigned?

If it were theoretically possible to discover that inter-router links 
were actually point to point links, should these be assigned /127's or 
the /80's instead?
That would preserve more /64's for end user systems. One mechanism could 
be to check the ND cache for other link local entries, other than other 
Homenet speaking routers?


I've also tried to add additional /62 prefixes to the DHCP PD server 
(fake ISP router) DHCPD config, but the Homenet either doesn't request 
these, or the ISC code isn't assigning them.
The homenet is thus only using a single lease, rather than concatenating 
multiple small leases.


That to me would either simulate the situation where multiple small 
leases were available from one ISP for utilization to number links from 
multiple prefixes, or a make before break renumbering event was upcoming.


Either way I'd expect the Homenet to somehow grab these additional 
leases if it had run out in the original PD assignment space, or to 
prepare for renumbering by assigning dual prefixes per link.


Is there anything to define in your draft?

e.g. Multiple address pools obtained from a single source SHOULD NOT be 
concatenated, but treated as a potential make before break renumbering 
event.


--
Regards,
RayH

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

Re: [homenet] I-D Action: draft-ietf-homenet-prefix-assignment-03.txt

[Ray Hunter]

Steven Barth mailto:cy...@openwrt.org
12 March 2015 18:11


I have read this draft. It looks very good.
I agree (having reviewed probably all the various iterations of that 
document).




I have the following questions:

1. What are the interoperability considerations if the node also 
contains (historical) configuration for acting as an RFC7084 router?


Especially with respect to requirement L2 and L8.
I think that is more of an implementation matter not so much 
draft-relevant. I mean sure if you design your OS from the ground up 
with that in mind that would be easy. However in the reference 
implementation we deliberately do not do that as that would require 
emulating a lot of OS-specific behavior.


You can however replicate this configuration by defining the interface 
as hnet with mode=leaf (i.e. always internal, not connected to routers 
= doesn't speak RP nor HNCP on it) and you can give hnet a hint on 
what size and or id of the prefix you want to have assigned.


As for L8 (running DHCPv6) hncp-04 has similar requirements, DHCPv6 
behavior was at some point actually in the PA draft but it was moved 
to hncp I suppose for clarity reasons though Pierre could probably 
talk about this in more detail.





2. may/should/must a Homenet router that participates in the 
draft-ietf-homenet-prefix-assignment-03.txt also act as a proxy for 
an old RFC7084 router connected to one interface?
This - as well - is defined in hncp-04 instead and we do this in the 
reference implementation. Internally the delegating router announces 
the DP on behalf of the legacy router using HNCP and inserts a local 
route.




Cheers,

Steven


I've just been testing this feature, which is why I asked ;)

/56 was requested by hnet router to ISP router.

/62 was (correctly) allocated to the 7084 router by the hnet router.
route to /62was (correctly) advertised by the hnet router into Homenet.

Is it not worth adding a couple of sentences to this draft?

At the end of Section 6:

Proxy:   A proxy node is capable of acting on behalf of one or more 
non-participating device(s) (e.g. a downstream RFC7084 compliant router) 
in order to assign new prefixes, adopting, existing ones, making 
overriding assignments and destroying existing ones on behalf of the 
non-participating device(s). The exact mechanism to be deployed is 
outside the scope of this draft. The proxy node SHOULD ensure that any 
underlying topology discovery mechanism is stable and complete, before 
acting as a proxy node, to avoid causing any race conditions. The proxy 
node SHOULD also check that the network topology beyond the proxy node 
is single attached to the set of participating nodes.


--
Regards,
RayH

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

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

[Ray Hunter]

Ted Lemon mailto:mel...@fugue.com
4 March 2015 16:20

I think you want an explicit update process for the glue records that 
is triggered by the DHCP server deprecating the old address. This 
would be related to how glue records are set up initially. The current 
document doesn't actually say anything about this, and that is a 
weakness that probably needs to be addressed.

Exactly.

Can this be handled in the Homenet WG? or DNS?

--
Regards,
RayH

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

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

[Ray Hunter]

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.


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.

--
Regards,
RayH

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

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

[Ray Hunter]

Mark Andrews mailto:ma...@isc.org
4 March 2015 08:04
In message54f6aace.3030...@globis.net, Ray Hunter writes:

Ted Lemonmailto:mel...@fugue.com
4 March 2015 03:21
On Mar 3, 2015, at 4:55 PM, Ray Hunterv6...@globis.net   wrote:

One hour TTL could mean 24 times the DNS traffic compared to that historic

  norm. It also could mean (re)signing DNSSEC zones more than 24 times per day
  as hosts move around the homenet...

Caching is really only interesting for query clusters and frequently access

ed domains.   I don't think there is any reason to expect that there will be
performance issues for homenet names, which I would expect would be infrequen
tly accessed by relatively few resolvers.
If I'm following draft-ietf-homenet-front-end-naming-delegation, then
the hidden master is also located within the Homenet.

Doesn't that mean that the (hidden master) DNS server itself also has to
be renumbered?

And the new content synched with the slave servers (outside of homenet)
in a timely manner, before the old prefixes are expired?

Are the values suggested in section 4.2 for SOA appropriate then?

I understood a zone transfer was only triggered when the SOA contents
changed, and that was only checked once the slave refresh timer had expired.


Zone transfers on SOA timer expiry very rarely happen these days.  NOTIFY
messages are the usual trigger.

Thanks. That rids me of one misconception then.

How does Homenet either update glue records for the domain on the 
Internet TLD servers (if the master isn't hidden), or update the 
configuration of the slave servers to point to the new address of the 
hidden master (if the master is hidden), within an hour or less?


Is that something that can also be automated and e.g. be triggered by an 
existing NOTIFY message?

Or would this mechanism need a new extension?

I'd rather not assume that the ISP was also the DNS provider.

Otherwise the slaves will lose connectivity to the hidden master (if the 
master is hidden) . Or your glue records will be outdated and the name 
resolution won't bootstrap at all (if the master isn't hidden).

You either have more name resolution traffic (every day), or you have more

  temporary addresses and old prefixes hanging around for longer (during a ren
umbering event, which is presumably not every day).

Temporary addresses don't belong in the DNS.   Stale information doesn't be

long in the DNS.   This seems like a no-brainer to me.
--
Regards,
RayH

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




--
Regards,
RayH

___
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

[Ray Hunter]

Daniel Migault wrote:

Hi,

Please find the new version of DHCP Options for Homenet Naming 
Architecture 
https://datatracker.ietf.org/doc/draft-ietf-homenet-naming-architecture-dhc-options/.


The issue raised on the previous version was how these options were 
compatible with multiple ISPs. This use case is illustrated in section 
A. 4 multiple ISPs.


BR,
Daniel


-- Forwarded message --
From: internet-dra...@ietf.org mailto:internet-dra...@ietf.org
Date: Tue, Feb 17, 2015 at 8:33 PM
Subject: [homenet] I-D Action: 
draft-ietf-homenet-naming-architecture-dhc-options-01.txt

To: i-d-annou...@ietf.org mailto:i-d-annou...@ietf.org
Cc: homenet@ietf.org mailto:homenet@ietf.org



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


Title   : DHCP Options for Homenet Naming Architecture
Authors : Daniel Migault
  Wouter Cloetens
  Chris Griffiths
  Ralf Weber
Filename: 
draft-ietf-homenet-naming-architecture-dhc-options-01.txt

Pages   : 28
Date: 2015-02-16

Abstract:
   CPEs are usually constraint devices with reduced network and CPU
   capacities.  As such, a CPE hosting on the Internet the authoritative
   naming service for its home network may become vulnerable to resource
   exhaustion attacks.  One way to avoid exposing CPE is to outsource
   the authoritative service to a third party.  This third party can be
   the ISP or any other independent third party.

   Outsourcing the authoritative naming service to a third party
   requires setting up an architecture which may be unappropriated for
   most end users.  To leverage this issue, this document proposes DHCP
   Options so any agnostic CPE can automatically proceed to the
   appropriated configuration and outsource the authoritative naming
   service for the home network.  This document shows that in most
   cases, these DHCP Options make outsourcing to a third party (be it
   the ISP or any ISP independent service provider) transparent for the
   end user.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-homenet-naming-architecture-dhc-options/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-homenet-naming-architecture-dhc-options-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-homenet-naming-architecture-dhc-options-01


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


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

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



--
Daniel Migault
Ericsson
I finally got around to reading this draft. It's been on my todo list 
for some time,


It looks very good, but I am missing the detail of how a renumbering 
event would be handled.


Is that the same process as adding a new Homenet CPE?

Worst case would seem to be where a user chooses scenario A3, but the 
ISP initiates a renumbering event without warning/coordination (new PD 
prefix).


My understanding of the plumbing is that something like BIND running on 
the Public Authoritative Master(s)  (slaves) would be hard-coded with a 
fixed IP addresses pointing at the hidden master running on the Homenet.
Configuring multiple masters is possible in BIND, so that's not an 
insurmountable barrier, and it would be possible to run with both 
addresses from the old and new prefixes simultaneously, and let BIND 
work out which one was reachable.


But maybe if the NOTIFY process in Section 5.1.1 from the CPE to the 
Public Authoritative Master(s) anyway already contains the address from 
the new prefix, and the process already checks validity and reachability 
of the hidden master before replacing the old entry, then maybe there's 
no need to run with multiple masters for any overlapping time at all.


The timing intrigues me.

--
Regards,
RayH

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

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

[Ray Hunter]

Mikael Abrahamsson wrote:

On Tue, 3 Mar 2015, Michael Sweet wrote:

True, but most video conferencing software and live video feeds 
handle disconnects gracefully (enough) already, and most streaming 
video is not done using a single file/URL but with a series of 
files/URLs, with each file/URL representing a chapter or other 
divisible unit within the program/movie being watched - there you 
will either seamlessly transition to the new address when the next 
chapter is fetched, or the application will detect the lost 
connection/stalled data and then attempt a reconnect which gets the 
new address.


So don't assume there will be problems when a network is renumbered - 
a lot of the work that's been done to deal with unreliable networks 
is equally useful for network changes, so long as the client 
application does not assume the network address of a named service 
won't change.


So where is the sweet spot? 10 minutes? 30 minutes? 1 hour? 3 hour? 6 
hour? 12 hour?


I just tried this. I was on the same subnet on wired ethernet and on 
wifi (etablished the call on wired with disabled wifi, enabled wifi, 
waited 30 seconds, then unplugged wired) using my OSX macbook, using 
Skype voice session with another skype user, and it took around 10 
seconds to detect the outage, and another 20 seconds to re-establish 
the call.


I tried the same procedure with Facetime audio, and it disconnected 
the call after 10 seconds and didn't try to establish it again until I 
manually did something.


Mosh fixes this with a 1-2 second outage.

I have no reason to believe the above behavior would be different if 
the call was over IPv6 (which I presume it wasn't) and the address 
went away because of a renumbering event.


So I'd say that at least two of the top VoIP clients on the market 
have no functionality to gracefully (30 second customer outage isn't 
gracefully) handling moving between two addresses. So applications 
need to get a *lot* better at being endpoint address independent.



I read your requirements.

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.


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 / we know from experience with Appletalk II NBP and ZIP that 100% 
dynamic a la minute server/name - address resolution doesn't scale well, 
and certainly not beyond enterprise level.


So we know we have to have some sort of caching in the name space. Or 
the list of partner addresses at the other end of the channel. Whatever. 
You cannot poll your partner on MOSH every 1mSec to see if it has 
changed its addresses.


I think caching in the name/address space sets a much more relevant 
lower limit on the speed of renumbering/ roaming via L3 on wifi/ 
whatever other event that causes your host's address(es) to change.


Otherwise you're forced into either taking your L3 prefix with you and 
using routing to the end host, or NATting the old address, or using 
rendezvous points, or being able to deprecate cache contents. None of 
which have proven particularly practicable.


So your 1 hour flash renumbering event seems way too small IMHO. 36 
hours would seem more reasonable.


I think that time limit is completely independent of a node's ability to 
fallback/fall forward to previously known alternative addresses (mSec 
range).


And for the wifi roaming example: if a node already knew all of the wifi 
prefixes in use in a Homenet, it could publish  records well in 
advance of any move for all possible interfaces it could attach to.



--
Regards,
RayH

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

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

[Ray Hunter]

Ted Lemon mailto:mel...@fugue.com
3 March 2015 20:36

Why do you say that? Is a ~60 minute TTL too short for a home device? 
I don't think so. As soon as the old address is deprecated, you remove 
the record pointing to it--you don't keep it around. You install  
records only for non-deprecated addresses. Why is this a problem? Why 
the need for a 36 hour timeframe?24 ho
36 hours is a number plucked out of thin air by me that is longer than 
24 hours, which is a historic default refresh time for many DNS servers 
e.g. RFC1912 https://www.ripe.net/ripe/docs/ripe-203 .
One hour TTL could mean 24 times the DNS traffic compared to that 
historic norm. It also could mean (re)signing DNSSEC zones more than 24 
times per day as hosts move around the homenet...


So it's clearly a trade off.

What's the difference in practical terms between 1 second, 1 minute, 1 
hour, and 1 day?


You either have more name resolution traffic (every day), or you have 
more temporary addresses and old prefixes hanging around for longer 
(during a renumbering event, which is presumably not every day).


Any operators got any input on how often they propose to rotate prefixes 
on domestic connections?


--
Regards,
RayH

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

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

[Ray Hunter]

Ted Lemon mailto:mel...@fugue.com
4 March 2015 03:21
On Mar 3, 2015, at 4:55 PM, Ray Hunterv6...@globis.net  wrote:

One hour TTL could mean 24 times the DNS traffic compared to that historic 
norm. It also could mean (re)signing DNSSEC zones more than 24 times per day as 
hosts move around the homenet...


Caching is really only interesting for query clusters and frequently accessed 
domains.   I don't think there is any reason to expect that there will be 
performance issues for homenet names, which I would expect would be 
infrequently accessed by relatively few resolvers.
If I'm following draft-ietf-homenet-front-end-naming-delegation, then 
the hidden master is also located within the Homenet.


Doesn't that mean that the (hidden master) DNS server itself also has to 
be renumbered?


And the new content synched with the slave servers (outside of homenet) 
in a timely manner, before the old prefixes are expired?


Are the values suggested in section 4.2 for SOA appropriate then?

I understood a zone transfer was only triggered when the SOA contents 
changed, and that was only checked once the slave refresh timer had expired.




You either have more name resolution traffic (every day), or you have more 
temporary addresses and old prefixes hanging around for longer (during a 
renumbering event, which is presumably not every day).


Temporary addresses don't belong in the DNS.   Stale information doesn't belong 
in the DNS.   This seems like a no-brainer to me.



--
Regards,
RayH

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

[homenet] Prefix Delegation, routing on the last hop ISP router, and draft-stenberg-v6ops-pd-route-maintenance-00

[Ray Hunter]

Following question may strictly speaking be out of scope for Homenet, as 
it is about the WAN side interface and interaction with the upstream ISP 
router.


Whilst setting up my own HNCP testbed, I was attempting to configure my 
own last-hop ISP router assuming a customer-owned Homenet router 
connected to my last-hop ISP router via Ethernet.

[also so I could do weird things/perform tests/interrupt/monitor DHCP PD]

Was there any further work done on 
draft-stenberg-v6ops-pd-route-maintenance-00?


Or is the Best Current Practice for non-point-to-point links still 
described in draft-stenberg-v6ops-pd-route-maintenance-00?


I was planning on using ISC DHCP 4.3.1 together with an external script 
as described in https://github.com/mpalmer/isc-dhcp contrib, to detect 
the next hop address of my homenet router and install the relevant route 
for the delegated prefix on the last-hop ISP router (a Linux box).


thanks

--
Regards,
RayH

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

Re: [homenet] A poll

[Ray Hunter]

Dave Taht wrote:

The homenet working group has been laboring for several years now to
find ways to make ipv6 more deployable to home (and presumably small
business) users.

In addition to multiple specification documents some code has been
produced to try and make things easier. At least in the USA, comcast
has rolled out IPv6 to everyone that can get dhcpv6 to sort of work on
their router, and/or is willing to install a custom firmware on their
router to get that, and of course tunneling ipv6 is possible if the
ISP does not support it.

So a quick poll:

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

Been using IPv6 in production at home since around 2010.

Main problems have been:

The assumptions manufacturers have made about how the boxes will be 
plugged together and assuming they're the only router in the home. Hence 
Homenet.
Several bugs in Apple airport and time capsule routers, blocking traffic 
incorrectly.

Lack of Protocol41 forwarding support in a lot of equipment.
Software updates killing 6to4 configured tunnel mode.
Cisco EPC3925 that refused to go into bridge mode (probably by design of 
the ISP).
Lack of fibre into the building means I'm stuck with the local cable 
provider, although there's net-neutral fibre in neighbouring streets 
supporting multiple native IPv6 providers.


1) Have you attempted to deploy a routing protocol in your home? Which
one, and why?
Yes. Static routing. Nothing else was supported in common, and I wanted 
a mail server on the outside in a DMZ and a private network on the inside.
It took a lot of tweaking to find a topology that worked simultaneously 
with IPv4 and supported what I wanted to do in IPv6.


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

Yes, but not tested too much yet as I've been moving a data centre.
Just bought a stack of WDR4300's to test with. Also with the intention 
of looking at mesh networking.

So hopefully I'll get around to it $day_job permitting.

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

Ethernet, powerline Ethernet, and wifi.

2 Raspberry Pi's
1 Linux server
2 iMacs
1 windows laptop
bunch of music sequencers and synths
1 printer
a couple of NAS boxes
a few wireless routers
guest devices
Apple TV
2 iPads
1 playstation

so probably ±10 hard wired. The rest wireless.

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

Yes I use wifi extensively.

I used range extension (Apple Airport Extreme) for a while, but ended up 
running a cable.



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

30?

Audio Visual Bridging (AVB) could throw a spanner in the works of having 
seamless connectivity throughout the home.
Hopefully someone will figure out a way of transmitting music/audio 
streams in a sample-coordinated manner at L3.

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

yes. Powerline IP to try to avoid running a cable. It wasn't too successful.


7) Do you use mdns service discovery?

Unfortunately yes, and I wonder how this will scale over L3.
UPnP too.

8) Why are you here? (especially, if your answers to 0-2, are no)
Because if Homenet does solve the ISP multihoming problem, and possibly 
the wifi roaming problems at L3, it will also be used extensively in SME 
and SOHO set ups, and perhaps even in campus-size deployments.


--
Regards,
RayH

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

Re: [homenet] Routing protocol comparison document

[Ray Hunter]

Mark Townsley wrote:


Dear WG,

In Hawaii, Margaret offered to pull together a document providing a 
summary of ISIS and Babel within the context of homenet. Working with 
Chris Hopps and Juliusz Chroboczek, Margaret just posted 
draft-mrw-homenet-rtg-comparison-01.txt. Many thanks to all 3 authors 
for this input, I'm sure it will help the WG make a more informed 
decision.


While there was a great deal of discussion and collaboration amongst 
the authors, this document does not represent the authors' consensus 
in its current form. This document is not intended to make a final 
recommendation one way or another at this time, rather it is a 
starting point for those who want more information but do not want to 
dive into the entire repertoire of documents (or code) for ISIS or Babel.


As such, I would like to invite everyone to use this as a starting 
point to familiarize yourselves with these two options. State your 
questions, comments, and opinions with at as much lively debate as we 
heard at the microphone and in the hallways in Hawaii.


Thank you,

- Mark


I have read this draft, as well as the WG discussion up until 18/2. 
Thanks to the authors for compiling this document.


I think there are still several clarification/improvement points to be 
made, even if we assume that this draft will never be published/serve as 
a useful reference beyond the life of the WG.


Section 4. seems to be largely irrelevant as currently written as far as 
I can see.


What would interest me more is whether there is a practical difference 
in behaviour given an unstable link in the Homenet network e.g. a 
powerline link that suffers from interference and bounces regularly.


Does IS IS behave differently to Babel when one link is unstable in the 
Homenet?


Is the forwarding freeze during link-state calculation at all 
significant, given the claimed convergence times?


Is there a significant difference in the (native) detection of neighbor 
down between the two protocols?


Or do they rely heavily on interface/link/carrier down?

I also don't currently see anything about interfaces to low power devices.

Is there a significant difference between Babel and IS IS behaviour in a 
completely stable network, especially with respect to battery life?


Section 12.

  The code size of IS-IS depends greatly on what aspects of the 
protocol have been implemented.



When talking about IS IS, I'm not entirely sure what we would be 
importing into Homenet if we did a #include IS-IS , and also what 
incompatibilities that might generate given multiple implementations 
with varying feature sets.


This comment has already been raised by others and I agree it requires 
further clarification. Exactly which feature set of IS IS are we talking 
about?


I also think there should also be more explicit links back into the 
Homenet Architecture document 
https://datatracker.ietf.org/doc/rfc7368/?include_text=1.


Especially section 3.5 where we agreed requirements for the routing 
protocol.


Perhaps a table with complies does not comply or partially 
complies per paragraph or phrase?



I'd also be interested in reading about the practicality of my 
smartphone being able to participate as a (stub) Homenet router. I think 
that's a nice use case for running code.


Would I need to jailbreak my phone to be able to load IS IS? or Babel? 
Especially re: access to operating system APIs?


If it's not there today, how difficult would it be for a 3rd party App 
Developer to build such a solution?


Or would users have to depend on the phone manufacturer incorporating 
Homenet out of the shrink wrap?


--
Regards,
RayH

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

Re: [homenet] dst/src routing drafts (for IETF-91 rtgwg)

[Ray Hunter]

Fred Baker (fred) mailto:f...@cisco.com
29 October 2014 17:09
On Oct 29, 2014, at 5:05 AM, Ray Hunterv6...@globis.net  wrote:


Fred Baker (fred) wrote:

On Oct 28, 2014, at 11:28 PM, David Lamparterequi...@diac24.net   wrote:


What I'm personally wondering most in this regard is: to what extent
will larger networks deploy multiple prefixes to the hosts?

Well, define “larger”. Any network that gets a PI prefix is unlikely to deploy 
multiple prefixes. The question is at what size network is makes sense to 
obtain an AS number and a PI prefix, and use BGP to talk with one’s upstream.

I don't agree with this statement for the following reasons.

Availability: There are many enterprises that have very numerous far-flung 
sales-office type locations which do not host any critical data or 
applications, but which could benefit from higher availability than that 
provided by a single ISP provider (some of which are currently served by a 
specialised box offering a Very Small Office Service running dual IPSec tunnels 
to a central site, which then performs the break out to the corporate 
intranet/Internet)

Latency: There are many sites which could benefit from local Internet breakout 
to regional cloud services, where you don't want to suffer the latency 
associated with a back haul from an office in Australia to a regional hub in 
Hong Kong, or even East coast US to West coast US and back. You'd still also 
want some back up via the central breakout if the local breakout failed.

Cost: There are cost savings to be made in many countries where private network 
services are still many orders of magnitude more expensive than plain old 
Internet. So Internet offload for non-mission-critical traffic can be very 
attractive. If you could achieve this via direct host-server connections using 
address selection rules or multipath TCP; rather than via PBR, GRE tunnels + 
NAT, that would be a lot simpler.


I have a hunch we’re talking past each other. We would agree, but we’re 
discussing different cases. I was discussing a case in which a company operates 
a single addressing plan. I think you’re discussing a company that operates 
multiple addressing plans, one for each of several locations.

Quite possibly.

Cisco might be an example of a “larger” company. We have an IPv6 /32, more 
locations than you can shake a stick at, and maybe 20 DMZs, places where our 
network interconnects with the Internet. I don’t know exactly what we advertise 
or where, but I could imagine that a few of our DMZs advertise the /32 and each 
of our DMZs advertises a /40, or something along that line. For us, PI is “duh, 
obvious”, and the only case in which we might - *might* - have a second prefix 
would be a ULA in a lab.
Well I think it's instructive to look at the current IPv4 unicast 
routing table and ask whether replicating this 1:1 into IPv6 is what 
enterprises really want.


Multihoming is far more than Internet.

External 3rd Party networks are often as big as, or even bigger than, 
an enterprises own Intranet.


If I look at some customer's current IPv4 routing tables, they contain: 
3rd party management companies for IT, speciality partners, per-project 
collaboration partners, private cloud, public cloud, merger demerger and 
assimilation targets, payment companies, 3rd party management companies 
for specialist equipment  hundreds of prefixes that aren't even 
managed by the enterprise in question, and with high churn rates too.


If I ask myself: do all product divisions of the business really want 
all of these differing communication requirements to get funneled 
through exactly the same handful of 3rd party touchpoints/DMZs to the 
outside world on a per region basis, I think the answer would 
emphatically be no.


IMHO Destination based routing (and ensuring balanced/ symmetric return 
routes for your own prefixes) imposes unnatural constraints on these 
touchpoints/DMZs, compared to what the business expects.


Why do you want to share a route to your crown-jewels /32 prefix, also 
used for your sales/finance platform, with someone who just manages some 
print servers for one product division on a number of sites via a 
dual-redundant 1Mbps link, whilst you have 10Gbps to the Internet? What 
happens if this 3rd party print server management company leaks your /32 
elsewhere via BGP into another AS? e.g. to another customer where they 
also manage their print servers, and who in turn are an important 
customer of your own products and want to connect to your front end 
sales site (via another higher-speed link).


It remains to be seen whether multiple-prefixes and SADR would help 
reduce this complexity, or just shift it around.


e.g. having a different prefix M assigned to a logical management 
interface on all print servers managed by party M, in addition to a 
prefix C used by the internal customers to connect to the business 
interface of the same servers.


You could have a default route for traffic 

Re: [homenet] dst/src routing drafts (for IETF-91 rtgwg)

[Ray Hunter]

Fred Baker (fred) wrote:

On Oct 28, 2014, at 11:28 PM, David Lamparterequi...@diac24.net  wrote:


What I'm personally wondering most in this regard is: to what extent
will larger networks deploy multiple prefixes to the hosts?


Well, define “larger”. Any network that gets a PI prefix is unlikely to deploy 
multiple prefixes. The question is at what size network is makes sense to 
obtain an AS number and a PI prefix, and use BGP to talk with one’s upstream.

I don't agree with this statement for the following reasons.

Availability: There are many enterprises that have very numerous 
far-flung sales-office type locations which do not host any critical 
data or applications, but which could benefit from higher availability 
than that provided by a single ISP provider (some of which are currently 
served by a specialised box offering a Very Small Office Service running 
dual IPSec tunnels to a central site, which then performs the break out 
to the corporate intranet/Internet)


Latency: There are many sites which could benefit from local Internet 
breakout to regional cloud services, where you don't want to suffer the 
latency associated with a back haul from an office in Australia to a 
regional hub in Hong Kong, or even East coast US to West coast US and 
back. You'd still also want some back up via the central breakout if the 
local breakout failed.


Cost: There are cost savings to be made in many countries where private 
network services are still many orders of magnitude more expensive than 
plain old Internet. So Internet offload for non-mission-critical traffic 
can be very attractive. If you could achieve this via direct host-server 
connections using address selection rules or multipath TCP; rather than 
via PBR, GRE tunnels + NAT, that would be a lot simpler.



  Wherever that boundary is, below that networks will use PA prefixes. The 
question then becomes: will they multi home?

And I think the answer today is that we don’t know the answer.

This I agree with.


--
Regards,
RayH

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

Re: [homenet] Securing HNCP - comments?

[Ray Hunter]

Markus Stenberg mailto:markus.stenb...@iki.fi
30 June 2014 09:31
On 28.6.2014, at 10.43, Ray Hunterv6...@globis.net  wrote:

How could [4] be prevented then? In ascending order of complexity..

[S4-1] Manual configuration of categories overriding automated border 
discovery. Defining either in the actual router product, or via configuration 
which interfaces to talk HNCP (and RP) on, where potential upstream links may 
never be, can be or always are.

[S4-2] Punt on security in HNCP, and just use e.g. IPsec with manual keying as 
currently specified in the draft. Setting up the shared PSK for the set of 
routers is left to the as manual configuration exercise for the owner of the 
devices.

[S4-3] HNCP-level PSK shared among all routers. Same bootstrap issues as 
[S4-2], may be able to get rid of manually keyed IPsec dependency.

[S4-4] Some public key cryptography solution operating with just raw keys 
(there is a draft in the works on how to do this in HNCP)

[S4-5] Some public key cryptography solution with CA hierarchy (similar to 
behringer-bootstrap)

The big question is, are the S4-3+ really worth it? And what is the sane way to 
do it if they are? Can we actually become RFC with just S4-1 and S4-2? In case 
we go for public key-cryptography: what do we do about routing protocols mostly 
relying on shared secrets for authentication?

- Markus and Steven

Powerline Ethernet devices have built in encryption, so I think consumers do 
expect some level of protection from accidental neighbouring. I agree with you 
questioning whether this should be solved at L2 or L3 and above.


Same thing with WPA* too of course. So I’m very tempted to assume L2 takes care 
of security.. ;)


Assuming the solution has to be defined at L3 and above, I think due to the 
lack of any hierarchy, or root node, that you're going to have to have 
individual keys/signatures per device, and that you cannot assume existence of 
a central keying repository.

S4-1 could work but relies on consumers plugging in devices into the correct 
ports. S4-2 does not meet the requirement for auto-configuration. S4-3 could 
work if you could bootstrap it, but that is not trivial either because it is 
chicken/egg. I don’t see S5-5 flying: there is no natural root node or root CA.


S4-2 and S4-3 have same characteristics in my view - they need some (consensus) 
way to generate PSK, that is then either a) fed to IPsec as manually keyed SA, 
or b) used to encrypt-authenticate content in the protocol.

S4-[45] have built-in ways of bootstrapping that are absent from S4-2/S4-3 as I 
see them.


The problem seems to boil down to how can we bootstrap the trust regardless 
of the encryption technology. Assuming S4-3 or S4-4, when a new device is added to the 
network (as opposed to existing devices being replugged) you could check it against a 
(distributed) DB of existing pairing keys (via TBD service discovery technology). If a 
device hasn't paired to at least one other homenet device, HNCP messages from this device 
is ignored until it has. Initiating the pairing should be as simple for the end user as 
pressing a button on 2 connected devices (nearly) simultaneously (one new and one already 
in the web of trust) so that both devices go into pairing mode and learn a new HNCP 
pairing. Once homenet is (relatively) stable, you would also be able to flood the new 
pairing to all other devices in the web of trust for potential long term storage. At some 
point you might end up seeing old devices you've given to your neighbour, so there should 
also be a way of clearing the pairing DB for a specific device, or automatically flushing 
entries for devices that have not been seen since time X. Alternative is that you have to 
put all devices in homenet into pairing mode simultaneously, but that may become less 
practical as the number of routers increases.
IF you can establish trust using HNCP (an expensive operation), it could be the 
basis for all other trust in the Homenet, so it is potentially a big win. e.g. 
To negotiate any necessary shared key for routing or other common Homenet wide 
parameters: think election of the root bridge in 802.1 and then that root 
device chooses a common shared key. Obviously distribution of the resulting 
shared keys from the root is going to have to be encrypted.


Yeah, I agree that this scheme (on high level) is what seems sensible _given_ 
the assumption you want to do the trust handling within HNCP.


I can certainly see this solution sketch requiring a lot of code.


Indeed, and be also nontrivial to specify and interoperably implement. Sigh.

So back to the original question, anyone have any idea if this stuff _must_ be 
implemented, really, beyond hand-wavy S4-1 and S4-2?  Looking at Babel, the 
routing protocol spec is 45 pages, and draft specification of HMAC security 
scheme for it is 55 pages. I sense some slight imbalance somewhere.

Cheers,

-Markus


To answer your question, I think you need to examine 

Re: [homenet] Securing HNCP - comments?

[Ray Hunter]

inline

Markus Stenberg wrote:

(This could have been a draft too, but I’m starting my vacation soon and I 
don’t want to post any more of those. Sorry.-Markus)

Current HNCP draft specifies security very vaguely, as it was originally based 
on just some napkin thoughts last year on ‘it would be nice to have 
authenticated TLVs’.

However, what are we protecting against, how, and should we go through the 
trouble at all? For all of these attacks, we have to assume _some_ network 
level access to a home network.

Let us consider potential attacks and their applicability on a home network:

[1] Pretend to be a client: no, we cannot protect against this, all clients are 
not currently authenticated and not in foreseeable future either. 802.1x not to 
even mention MACSec support on wired ports is mostly nonexistent in home 
routers.

[2] Replace upstream router on the upstream link. We cannot do anything about 
this, and as your packets already go to e.g. NSA, assumption of privacy is moot 
so this battle is lost. This attack may be harder to mount due to upstream link 
being typically wired, hard to reach, etc.

[3] Pretend to be upstream router on some other link. We can protect against 
this with fixed categories of interfaces, but securing HNCP has nothing to do 
with it as upstream router doesn’t talk HNCP.

[4] Pretend to be an inner router.

What are their implications?

[1]: Any resource in-home _can_ be accessed and there is not much that can be 
done given access to a non-guest link.

[2,3]: Any traffic on the Internet is public (and what else is new?).

[4]: If impersonation is possible, man-in-the-middle and potentially denial of 
service attacks on home network become possible.

How could [4] be prevented then? In ascending order of complexity..

[S4-1] Manual configuration of categories overriding automated border 
discovery. Defining either in the actual router product, or via configuration 
which interfaces to talk HNCP (and RP) on, where potential upstream links may 
never be, can be or always are.

[S4-2] Punt on security in HNCP, and just use e.g. IPsec with manual keying as 
currently specified in the draft. Setting up the shared PSK for the set of 
routers is left to the as manual configuration exercise for the owner of the 
devices.

[S4-3] HNCP-level PSK shared among all routers. Same bootstrap issues as 
[S4-2], may be able to get rid of manually keyed IPsec dependency.

[S4-4] Some public key cryptography solution operating with just raw keys 
(there is a draft in the works on how to do this in HNCP)

[S4-5] Some public key cryptography solution with CA hierarchy (similar to 
behringer-bootstrap)

The big question is, are the S4-3+ really worth it? And what is the sane way to 
do it if they are? Can we actually become RFC with just S4-1 and S4-2? In case 
we go for public key-cryptography: what do we do about routing protocols mostly 
relying on shared secrets for authentication?

- Markus and Steven
Powerline Ethernet devices have built in encryption, so I think 
consumers do expect some level of protection from accidental 
neighbouring. I agree with you questioning whether this should be solved 
at L2 or L3 and above.


Assuming the solution has to be defined at L3 and above, I think due to 
the lack of any hierarchy, or root node, that you're going to have to 
have individual keys/signatures per device, and that you cannot assume 
existence of a central keying repository.


S4-1 could work but relies on consumers plugging in devices into the 
correct ports. S4-2 does not meet the requirement for 
auto-configuration. S4-3 could work if you could bootstrap it, but that 
is not trivial either because it is chicken/egg. I don't see S5-5 
flying: there is no natural root node or root CA.


The problem seems to boil down to how can we bootstrap the trust 
regardless of the encryption technology. Assuming S4-3 or S4-4, when a 
new device is added to the network (as opposed to existing devices being 
replugged) you could check it against a (distributed) DB of existing 
pairing keys (via TBD service discovery technology). If a device hasn't 
paired to at least one other homenet device, HNCP messages from this 
device is ignored until it has. Initiating the pairing should be as 
simple for the end user as pressing a button on 2 connected devices 
(nearly) simultaneously (one new and one already in the web of trust) so 
that both devices go into pairing mode and learn a new HNCP pairing. 
Once homenet is (relatively) stable, you would also be able to flood the 
new pairing to all other devices in the web of trust for potential long 
term storage. At some point you might end up seeing old devices you've 
given to your neighbour, so there should also be a way of clearing the 
pairing DB for a specific device, or automatically flushing entries for 
devices that have not been seen since time X. Alternative is that you 
have to put all devices in homenet into pairing mode simultaneously, but 

Re: [homenet] Updates to Homenet Architecture Principles doc

[Ray Hunter]

Tim Chown mailto:t...@ecs.soton.ac.uk
17 June 2014 18:11
Hi Ray,

I like your questions, and I think many of your own suggested answers 
to your questions are in line with what I believe the WG has assumed 
in its discussions. I find myself in agreement with most (and perhaps 
all) of them.

Glad to read that.
 But obviously I can’t speak for the WG, only my perception of WG 
consensus as the document editor.
I certainly don't claim to speak for the WG : I just hope my 
contribution moves the discussion on in a constructive way.


I would say we did shy away from a specific answer on a separate 
configuration protocol in London, but since then HNCP has evolved.

ACK.

I agree the multi-path clarification is needed.

ACK.


I think Alex is heading into too much detail, when we are trying to 
avoid that (what Ray describes are general principles).


I’m talking with Ted and the chairs on the approach to take.  Expect 
news soon :)

Thanks.


Tim





--
Regards,
RayH

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

Re: [homenet] Updates to Homenet Architecture Principles doc

[Ray Hunter]

Juliusz Chroboczek wrote:

The inclusion of physical layer characteristics including bandwidth,
loss, and latency in path computation should be considered for
optimising communication in the homenet.



Should the text then rather say Path selection in Homenet needs to be
more sophisticated than measuring pure hop count due to the use of
heterogeneous link technologies, and therefore the routing protocol should
be capable of utilising multiple link-dependent metrics, such as
bandwidth, delay, and link reliability, rather than mentioning
optimised?


I'm happy with either.  The current text leaves it to the protocol people
to decide what optimising means, but I also like the way you spell out
the requirement.  If you'll allow me to indulge in some minor nit picking
wrt. your suggested wording:

  - you require multiple [...] metrics, which is what we do in Babel, but
we certainly don't wish to prevent somebody from being smart enough to
design a single metric that works satisfactorily on all link layers;
  - you use bandwdith where you mean throughput (yeah, I know, I'm
a pedant);
  - I'm on a personal crusade against the utilisation of the verb to utilise.

So perhaps something like:

   Due to the use of heterogeneous link technologies, path selection in
   a homenet needs to be more refined than minimising hop count.  The
   homenet routing protocol should be able to select paths according to
   criteria such as latency, throughput, link reliability (e.g. measured
   packet loss) or other performance metrics.

-- Juliusz


I could certainly live with your text, and if the WG ever moved to 
evaluating competing candidate routing protocols against requirements 
derived from the architecture, it could provide a useful and objective 
differentiator, which is possibly something that has been lacking up 
until now. e.g. {BABEL,  EIGRP, full IS-IS .} might be preferred 
over {OSPFv3} which might be preferred over {RIPng, HNCP native 
routing, IS-IS (only using cost and default cost=10) , AODV (without 
link quality extensions) } on this particular measure of suitability.


--
Regards,
RayH

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

Re: [homenet] Updates to Homenet Architecture Principles doc

[Ray Hunter]

Juliusz Chroboczek wrote:

So even though link-local multicast may be part of the IPv6 base spec,
it may be desirable to avoid use of multicast traffic where
possible. e.g. a routing protocol could perform initial neighbor
discovery using multicast, but then switch to unicast when maintaining
individual neighbor associations on the longer term, or for exchanging
information with specific neighbors.


Ah, I see.  Yes, that makes sense.


Then I think I don't understand what is meant by multi-path support.  Is
that merely the ability to switch to a better route if one becomes
available?  Or is there something more to it?  Could you please clarify?



The inclusion of physical layer characteristics including bandwidth,
loss, and latency in path computation should be considered for
optimising communication in the homenet.



I interpret the above text as requesting an ability to perform load
balancing over equal cost paths, potentially taking into account packet
loss and link quality when selecting which stream to send over which link.


I don't.  I interpret that as meaning that the routing protocol should be
able to pick a path using more refined criteria than just hop count.
E.g. to prefer a 1Gb/s link to a 100Mb/s one, or to prefer two wired hops
to a single wireless one.  Doing that is not too difficult, and yields
dramatic performance improvements in some fairly simple, realistic
topologies.

Load sharing is a completely different headache.  Done carelessly, load
sharing causes issues with increased latency and jitter, and causes
intermittent connectivity problems that are very difficult to troubleshoot
if one of the links is unreliable.  It also has ghastly performance if you
balance across wireless links without taking radio interference into account.

While it's certainly an area worth experimenting with, I'd be cautious
about requiring load sharing in Homenet unless somebody knows how to do it
right in the general unadministered case.

-- Juliusz


Your interpretation of the current architecture text also seems 
perfectly valid, and is indeed much simpler to implement.


Should the text then rather say Path selection in Homenet needs to be 
more sophisticated than measuring pure hop count due to the use of 
heterogeneous link technologies, and therefore the routing protocol 
should be capable of utilising multiple link-dependent metrics, such as 
bandwidth, delay, and link reliability, rather than mentioning optimised?


IMHO That revised text would provide a very clear selection criteria for 
preferring certain routing protocols over others.


Or do you think the text is OK as is?

--
Regards,
RayH

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

Re: [homenet] Updates to Homenet Architecture Principles doc

[Ray Hunter]

Tim Chown wrote:


On 13 Jun 2014, at 14:57, Ted Lemon mel...@fugue.com 
mailto:mel...@fugue.com wrote:


On Jun 13, 2014, at 9:48 AM, Lorenzo Colitti lore...@google.com 
mailto:lore...@google.com wrote:
Not to me they didn't. Seriously - if you understand what we're 
being asked to do, and it's simple to explain, then it shouldn't 
take long for you to type. Please?


The working group would presumably like for there to be routing on 
the homenet.   What problems is the routing supposed to solve?   What 
things are priorities?   What things aren't priorities?


Clearly we need the routing solution to get packets to the right 
egress based on source address.   Do we also need it to do load 
sharing across parallel links, if such links exist?   Is it important 
to minimize the number of hops? 


Para 7 of 3.5:
It may be beneficial for traffic to use multiple paths to
a given destination within the homenet where available, rather than a
single best path.

 How long of a delay can there be between changes to the topology 
(e.g., a router being unplugged) and recovery, assuming that a flow 
was going through that router? 


Para 6 of 3.5:
Minimising convergence time should be a goal in any
routed environment, but as a guideline a maximum convergence time at
most 30 seconds should be the target (this target is somewhat
arbitrary, and…“

Is it okay to break a flow in that situation, or does it need to 
survive the transition? 


Not stated.  Should it be different to the border router resetting?

Does the routing protocol need to be aware of the type of media a 
given link crosses, and does it need to prefer one media type over 
another where both are available?


Para 5 of 3.5:
Multiple types of physical interfaces must be accounted for in the
homenet routed topology.  Technologies such as Ethernet, WiFi,
Multimedia over Coax Alliance (MoCA), etc. must be capable of
coexisting in the same environment and should be treated as part of
any routed deployment.The inclusion of physical layer
characteristics including bandwidth, loss, and latency in path
computation should be considered for optimising communication in the
homenet.“

I'm basically making questions up here.   The document should say 
what the working group wants routing to accomplish.   Right now it's 
a bit of a kitchen sink, with a lot of (IMHO) inappropriately 
prescriptive text.


Well, 3 of the 4 questions seem to be answered, or at least considered 
if left relatively open.


Tim



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




OK. Ted asked for additional questions and answers, and I think he has a 
point in that there should be hooks to requirements in the architecture 
that facilitate selection of the correct routing protocol(s) later, 
without unnecessarily limiting the choice.



Here's my contribution after going through a few comparisons texts of 
common routing protocols that I found online. I pose a question, give my 
personal view, and then check if I can find an answer in the current text.



Does the Homenet Architecture require the routing protocol to carry 
arbitrary configuration information?
[my view] No. Assuming the existence of a separate Homenet configuration 
protocol, the routing protocol must facilitate auto-configuration, but 
does not necessarily have to supply configuration to other processes.

[this is not currently explicitly defined the architecture document AFAICS]


Does the Homenet Architecture require the routing protocol to support 
multiple address families?
[my view] No. The Homenet architecture is IPv6 only. Although support 
for IPv4 and other address families may be beneficial, it is not an 
explicit requirement to carry the routing information in the same 
routing protocol.

[this is not currently in the architecture document AFAICS]


Does the Homenet Architecture require the routing protocol to support SADR?
[my view] Yes.
[this is in the current architecture document]

A routing protocol that can make routing
   decisions based on source and destination addresses is thus
   desirable, to avoid upstream ISP BCP 38 ingress filtering problems.


Does the Homenet Architecture require the routing protocol to be 
tolerant of lossy unstable links?

[my view] Yes.
[this is in the current architecture document]
Technologies such as Ethernet, WiFi,
   Multimedia over Coax Alliance (MoCA), etc. must be capable of
   coexisting in the same environment and should be treated as part of
   any routed deployment. The inclusion of physical layer
   characteristics including bandwidth, loss, and latency in path
   computation should be considered for optimising communication in the
   homenet.


Does the Homenet Architecture explicitly require use of a distance 
vector or link state algorithms?

[my view] No. The Homenet architecture should be agnostic on this 

Re: [homenet] Updates to Homenet Architecture Principles doc

[Ray Hunter]

Juliusz Chroboczek mailto:j...@pps.univ-paris-diderot.fr
14 June 2014 16:25

Is a specific update address preferred?
[my view]   The routing protocol should support both use of unicast and
multicast updates.


Please clarify.  Are you saying that the routing protocol must be able to
run over link layers that don't support link-local multicast?  AFAIK,
link-local multicast is part of the base IPv6 spec.


Multicast has issues on some link topologies (e.g. where it has to be 
emulated), and in situations where devices attempt to sleep for as long 
as possible. So even though link-local multicast may be part of the IPv6 
base spec, it may be desirable to avoid use of multicast traffic where 
possible. e.g. a routing protocol could perform initial neighbor 
discovery using multicast, but then switch to unicast when maintaining 
individual neighbor associations on the longer term, or for exchanging 
information with specific neighbors.

Multi-path support?
[my view] yes.
[this is in the current architecture document]


Then I think I don't understand what is meant by multi-path support.  Is
that merely the ability to switch to a better route if one becomes
available?  Or is there something more to it?  Could you please clarify?

-- Juliusz

I don't know that there is a single definition.

The inclusion of physical layer
   characteristics including bandwidth, loss, and latency in path
   computation should be considered for optimising communication in the
   homenet.

I interpret the above text as requesting an ability to perform load 
balancing over equal cost paths, potentially taking into account packet 
loss and link quality when selecting which stream to send over which link.
Another possible interpretation of the text would be an ability to route 
packets based on traffic type, e.g. policy based routing of video 
traffic over a different link to FTP.

Or a combination of the above.

If you have a better interpretation or definition then please share.







--
Regards,
RayH

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

Re: [homenet] Updates to Homenet Architecture Principles doc

[Ray Hunter]

Here's my 2c worth on Section 3.5

I'm on record as preferring a common Homenet routing protocol without 
having any fingers in any particular choice.


I believe there is rough consensus around the choice of 0 or 1 routing 
protocol.


Going through Section 3.5 line by line.



Routing functionality

   Routing functionality is required when there are multiple routers
   deployed within the internal home network.  This functionality could
   be as simple as the current 'default route is up' model of IPv4 NAT,
   or, more likely, it would involve running an appropriate routing
   protocol.  Regardless of the solution method, the functionality
   discussed below should be met.

Fine by me.


   The homenet unicast routing protocol should be based on a previously
   deployed protocol that has been shown to be reliable and robust, and
   that allows lightweight implementations, but that does not preclude
   the selection of a newer protocol for which a high quality open
   source implementation becomes available.  Using information
   distributed through the routing protocol, each node in the homenet
   should be able to build a graph of the topology of the whole homenet
   including attributes such as links, nodes, connectivity, and (if
   supported by the protocol in use) link metrics.


Fine by me. Apart from the use of the word graph which could be 
overloaded or suggest a preference for link state protocols. 
s/graph/consistent view/ ?



   The routing protocol should support the generic use of multiple
   customer Internet connections, and the concurrent use of multiple
   delegated prefixes.  A routing protocol that can make routing
   decisions based on source and destination addresses is thus
   desirable, to avoid upstream ISP BCP 38 ingress filtering problems.
   Multihoming support should also include load-balancing to multiple
   providers, and failover from a primary to a backup link when
   available.  The protocol however should not require upstream ISP
   connectivity to be established to continue routing within the
   homenet.

Fine be me.


   Routing within the homenet will determine the least cost path across
   the homenet towards the destination address given the source address.
Too explicit IMHO. What is wrong with s/determine the least cost path 
across the homenet towards the destination address given the source 
address /maintain a loop free forwarding path between any given source 
address and destination pair/

   The path cost will be computed as a linear sum of the metric assigned
   to each link.
Way too explicit IMHO. EIGRP is a perfectly good routing protocol that 
would be excluded by this requirement as the routing metric is a non 
linear sum of different individual link metrics, including minimum path 
bandwidth.
Not that I'm urging use of EIGRP, but I don't see why it should be 
excluded on these grounds alone.



The metric may be configured or automatically derived
   per link based on consideration of factors such as worst-case queue
   depth and router processing capabilities.


It's a may so fine by me.

   Multiple types of physical interfaces must be accounted for in the
   homenet routed topology. 

Fine be me.

Technologies such as Ethernet, WiFi,
   Multimedia over Coax Alliance (MoCA), etc. must be capable of
   coexisting in the same environment and should be treated as part of
   any routed deployment.

Fine be me.

The inclusion of physical layer
   characteristics including bandwidth, loss, and latency in path
   computation should be considered for optimising communication in the
   homenet.


Fine be me.

   The routing environment should be self-configuring, as discussed
   previously.  Minimising convergence time should be a goal in any
   routed environment,

Fine by me.

but as a guideline a maximum convergence time at
   most 30 seconds should be the target (this target is somewhat
   arbitrary, and was chosen based on how long a typical home user might
   wait before attempting another reset; ideally the routers might have
   some status light indicating they are converging, similar to an ADSL
   router light indicating it is establishing a connection to its ISP).

Way too explicit IMHO. I don't see why a figure of 30 seconds for 
convergence time is even given. I'm not happy to wait 30 seconds for 
video distribution over Homenet.
Surely acceptable convergence time is a function of user expectations 
relative to the nature of the traffic being carried by the Homenet, 
combined with the available buffering before the user becomes aware of 
any topology change.

   Homenets may use a variety of underlying link layer technologies, and
   may therefore benefit from being able to use link metrics if
   available.  It may be beneficial for traffic to use multiple paths to
   a given destination within the homenet where available, rather than a
   single best path.

Fine be me. But is totally inconsistent with the sentence above to 
always choose the 

Re: [homenet] HNCP: Few proposed changes for next draft version

[Ray Hunter]

Steven Barth wrote:

Hello everyone,

I prepared the first few changes for the upcoming HNCP draft version 
01. Most of this is derived from features we already added to our 
reference implementation.



1. Backwards-compatibility with RFC 7084 routers.

Diff: 
https://github.com/fingon/ietf-drafts/commit/c193f27f036175ac5a006fe3df1a1ea8f908975d 




Looks like a can of worms to me.

How do you intend to do this?

Are there Homenet topology limitations?

How will the user know not to plug the LAN interface of a 7084 router 
into a WAN interface?


7084 (6204bis) was intended to be a dead end once Homenet completed AFAICS.



2. HNCP-routers should make interface categories (auto, internal, 
external) configurable and MAY offer additional categories (guest, 
ad-hoc).


Diff: 
https://github.com/fingon/ietf-drafts/commit/47fdf57a1759fad6e8c6c29d741e95039aca671e 


Agreed. Sensible.



3. Some house-keeping (updating references, fixing idnits warnings)

Diff: 
https://github.com/fingon/ietf-drafts/commit/a2e2aa1f43e91e808af56f31e5ad514568fc8a6a 





Agreed.


Feedback is welcome.


Regards,

Steven




--
Regards,
RayH

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

Re: [homenet] HNCP: Few proposed changes for next draft version

[Ray Hunter]

Steven Barth mailto:cy...@openwrt.org
3 June 2014 09:15

Well maybe it was worded a bit ambiguously. The main idea behind this 
was that an HNCP router should provide basic connectivity in the 
form of DHCPv4 and DHCPv6-PD to non-HNCP-routers. 7084 routers should 
not do anything fancy and just work as legacy devices believing the 
homenet is their ISP.


This should not mean you should be able to tunnel through 7084 
routers or so.


Does that sound sane? And maybe what would be a better wording for 
this idea?


It is a sane idea, and I applaud any manufacturer that can prevent that 
a lot of 7084 routers are destined for the landfill sooner than they 
should be.


But it's still a can of worms and you should think very carefully 
whether you want this as a SHOULD in HNCP. I humbly suggest MAY at most.


e.g. What about the topology:

Homenet router - Homenet Router
||
||
L2 switch e.g. Powerline Ethernet
  |
  |
 7084 router

Which Homenet router acts as the Service Provider Router of 7084?

That's even before considering the question, what do you do when the 
7084 router is inserted between two Homenet routers?


In fairness I should declare that I was extremely skeptical about 
publishing 7084, and whether it would be harmful for Homenet.


--
Regards,
RayH

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

Re: [homenet] Single or Multiple Routing Protocols in Homenet

[Ray Hunter]

Liubing (Leo) wrote:

Hi all,

We have an ISIS auto-configuration draft under developing in ISIS WG 
(draft-liu-isis-auto-conf). Since Homenet/SME networks are one of the main 
scenarios our draft targets at, and we already have an OSPF-autoconf mechanism 
available (draft-ietf-ospf-ospfv3-autoconfig), during the isis meeting some 
people raised the question whether Homenet WG want to support multiple IGP 
auto-configuration mechanisms.

I checked the meeting minutes of the last Homenet meeting. And found the status 
of the issue is:
- WG had decided to have both a configuration protocol (HNCP) + a routing 
protocol
- WG hasn't decided to have only one routing protocol or two, or even N...
- it seems only one routing protocol has more support

May I ask a couple of questions:

1) Is it necessary to enforce only one routing protocol?
If HNCP is adopted, I guess multiple routing protocols could be easily 
supported ?
I think it might be more flexible if homenet router support multiple routing 
protocols. Is there any harm?
(Note: supporting multiple routing protocols here doesn't mean they need run at 
the same time, just more choices.)

2) If we decide to have only one, then what is the criteria for protocol 
selection?

Look forward to your comments. Many thanks.

Best regards,
Bing




I use IS-IS in a provider setting, where it has advantages.

There is already a draft in 6man regarding how to signal SADR routes to 
end nodes http://tools.ietf.org/html/draft-sarikaya-6man-next-hop-ra-01


I am of the opinion that the need to communicate source address based 
routing information to end nodes in Homenet will only increase, or else 
it will turn out that there will be many more end nodes that should 
actually be mobile Homenet routers e.g. mobile phones with multiple 
radios and fixed dock connections. The logical step then from IS-IS 
would be that these devices either speak ES-IS or translating metrics 
into RA or running IS-IS on end devices.


With that in mind, I think it would be harmful to add a requirement for 
Homenet routers (and perhaps many mobile nodes) to speak an OSI protocol.
It's yet another protocol stack, we already have alternatives, and it 
isn't widely supported on many operating systems out of the shrink wrap.


--
Regards,
RayH

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

Re: [homenet] HNCP: Few proposed changes for next draft version

[Ray Hunter]

Steven Barth mailto:cy...@openwrt.org
3 June 2014 09:54

Am 03.06.2014 09:40, schrieb Ray Hunter:

Steven Barth mailto:cy...@openwrt.org
3 June 2014 09:15

Well maybe it was worded a bit ambiguously. The main idea behind 
this was that an HNCP router should provide basic connectivity in 
the form of DHCPv4 and DHCPv6-PD to non-HNCP-routers. 7084 routers 
should not do anything fancy and just work as legacy devices 
believing the homenet is their ISP.


This should not mean you should be able to tunnel through 7084 
routers or so.


Does that sound sane? And maybe what would be a better wording for 
this idea?


It is a sane idea, and I applaud any manufacturer that can prevent 
that a lot of 7084 routers are destined for the landfill sooner than 
they should be.
I guess this would not only apply to 7084 routers but current 
IPv6-capable homerouters in general in the end.




But it's still a can of worms and you should think very carefully 
whether you want this as a SHOULD in HNCP. I humbly suggest MAY at most.

I guess I'm fine with that.



e.g. What about the topology:

Homenet router - Homenet Router
||
||
L2 switch e.g. Powerline Ethernet
  |
  |
 7084 router

Which Homenet router acts as the Service Provider Router of 7084?
The behavior is essentially the same as with clients right now. One 
homenet router per link is elected as DHCP / DHCPv6-server. The only 
addition here is that this elected router now acts as PD-server as well.




That's even before considering the question, what do you do when the 
7084 router is inserted between two Homenet routers?
This should be same as the current situation: If you are lucky that 
7084 router gives you PD then you have essentially two separate 
homenets, if not that homenet router behind the legacy one gets no 
(IPv6)-connectivity and probably nasty IPv4 double-NATs.  There is not 
much you can do though except teach that router to speak homenet.




Homenet router ---PD--7084 router -- PD Homenet Router
|   | |
|   v PD  |
|   | |
 ---L2 switch e.g. Powerline Ethernet 
|
|
 7084 router


PD loops? End users are creative.



In fairness I should declare that I was extremely skeptical about 
publishing 7084, and whether it would be harmful for Homenet.


Well I guess it doesn't really do much in favor of homenet by 
proclaiming: there is only the ISP on one side and clients on the 
other side you need to care about. Well at least it defines some sane 
requirements (and some less sane ones) regarding these 2 issues.
It was decided that any updates to 6204 for the WAN interface would be 
out of scope for 7084 and that these would instead be deferred into Homenet.


--
Regards,
RayH

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

Re: [homenet] HNCP: Few proposed changes for next draft version

[Ray Hunter]

Timothy Winters mailto:twint...@iol.unh.edu
3 June 2014 23:02
On Jun 3, 2014, at 4:02 PM, Brian E Carpenterbrian.e.carpen...@gmail.com  
wrote:


On 04/06/2014 01:34, Michael Richardson wrote:

Steven Barthcy...@openwrt.org  wrote:

Well maybe it was worded a bit ambiguously. The main idea behind this was
that an HNCP router should provide basic connectivity in the form of
DHCPv4 and DHCPv6-PD to non-HNCP-routers. 7084 routers should not do
anything fancy
and just work as legacy devices believing the homenet is their ISP.

If the person connects things in the wrong order, should we be documenting
the heuristics that would permit the HNCP router to detect this situation?

Let's get real. Users *will* mix and match RFC7084, RFC6204 and neither-of-
the-above IPv6 routers with HNCP-capable routers. If we can't deal with
routers that are blind to HNCP in a reasonable way, those users will
be unhappy. Indeed, the first stage is for HNCP routers to discover
the existence of HNCP-blind routers.

Brian

The following draft can from the homenet design team 
(http://tools.ietf.org/html/draft-winters-homenet-sper-interaction-01) tries to 
cover the border scenarios for 6204, 7084 and other routers (SPERs) when 
interacting with the Homenet.   It doesn't cover the case for routers inside a 
homenet but as Steven pointed out that can be two separate border router.

~Tim

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


I don't read anything in 7084 about providing PD on the LAN interfaces. 
In fact it states that it must act as a requesting router not a 
delegating router


So I don't see how the scenario of a 7084 compliant router acting as a 
border router or ISP router is going to pan out: a 7084 router only 
assigns one /64 per LAN interface (requirement L-2)



Brian E Carpenter mailto:brian.e.carpen...@gmail.com
3 June 2014 22:02

Let's get real. Users *will* mix and match RFC7084, RFC6204 and 
neither-of-

the-above IPv6 routers with HNCP-capable routers. If we can't deal with
routers that are blind to HNCP in a reasonable way, those users will
be unhappy. Indeed, the first stage is for HNCP routers to discover
the existence of HNCP-blind routers.

Brian
That's a tautology. 7084 and 6204 were explicitly designed with an 
architecture of a single router and flat user LANs. If these existing 
standards supported cascaded routers in any way, we probably wouldn't 
need Homenet.


They also cannot be assumed to deal with anything other than a default 
route (requirement W-3), SADR, or multiple upstream neighbours AFAICS 
(all requirements for PD in WPD-1 - WPD-5 talk about a (single) prefix 
(L-13) and single PD request (W-4), or that they have a facility to 
disable BCP 38 filtering (S-2).


So IHMO they're going to be limited at most to leaf nodes at the edge of 
the Homenet. And even then they're probably going to break naming.


Anything else will be a guess, as your HNCP discovery traffic will be 
blocked and you can't detect if this is a single 7084 router blocking 
HNCP, or two 7084 routers cascaded in series, or an entire homenet 
sandwiched between them.

Michael Richardson mailto:mcr+i...@sandelman.ca
3 June 2014 15:34
Steven Barth cy...@openwrt.org wrote:
 Well maybe it was worded a bit ambiguously. The main idea behind 
this was

 that an HNCP router should provide basic connectivity in the form of
 DHCPv4 and DHCPv6-PD to non-HNCP-routers. 7084 routers should not do
 anything fancy
 and just work as legacy devices believing the homenet is their ISP.

If the person connects things in the wrong order, should we be documenting
the heuristics that would permit the HNCP router to detect this situation?

--
Michael Richardson mcr+i...@sandelman.ca, Sandelman Software Works
-= IPv6 IoT consulting =-



Steven Barth mailto:cy...@openwrt.org
3 June 2014 09:15

Well maybe it was worded a bit ambiguously. The main idea behind this 
was that an HNCP router should provide basic connectivity in the 
form of DHCPv4 and DHCPv6-PD to non-HNCP-routers. 7084 routers should 
not do anything fancy and just work as legacy devices believing the 
homenet is their ISP.


This should not mean you should be able to tunnel through 7084 
routers or so.


Does that sound sane? And maybe what would be a better wording for 
this idea?

Ray Hunter mailto:v6...@globis.net
3 June 2014 09:05


Steven Barth wrote:

Hello everyone,

I prepared the first few changes for the upcoming HNCP draft version 
01. Most of this is derived from features we already added to our 
reference implementation.



1. Backwards-compatibility with RFC 7084 routers.

Diff: 
https://github.com/fingon/ietf-drafts/commit/c193f27f036175ac5a006fe3df1a1ea8f908975d 




Looks like a can of worms to me.

How do you intend to do this?

Are there Homenet topology limitations?

How will the user know not to plug the LAN interface of a 7084 router 
into a WAN interface?


7084 (6204bis

Re: [homenet] WG adoption of draft-stenberg-homenet-hncp-00

[Ray Hunter]

Pierre Pfister mailto:pierre.pfis...@darou.fr
27 March 2014 08:50
Le 27 mars 2014 à 08:19, Ray Hunterv6...@globis.net  a écrit :


Mikael Abrahamssonmailto:swm...@swm.pp.se
27 March 2014 07:04
On Wed, 26 Mar 2014, Ray Hunter wrote:


HNCP as it stands right now has a routing protocol of it's own that is extremely 
rudimentary, but it gets the job done. I think this is what is referred to as zero routing 
protcol because people don't really want to call it a routing protocol (my interpretation).




That is my understanding of the zero routing protocol » too.


Right, but the way I see it:

If you have an arbitrary topology then you probably need to carry metrics to 
prefer one link type over another.
If you want to be able to determine which prefixes to delete from the FIB and 
RA when a particular upstream provider link goes down, you probably need some 
sort of tagging.
If you want fast convergence around failures you probably need a decent path 
discovery algorithm.
If you want to differentiate between a temporary change (due to an incident or 
link failure) and a longer term permanent change (due to replugging or device 
insertion or removal) then you probably need two different sets of timers and 
problem diagnostics.

In other words; we definitely need a routing protocol, and probably a 
configuration protocol too.

So isn't the danger than HNCP starts off being very simple, and ends up 
duplicating a lot of previous work and experience?

I'm interested to hear the contrarian view.


Except the second point (determine which prefix to delete…), which is done by 
the prefix assignment algorithm on top of HNCP, all other points will have to 
be answered to decide which routing protocol to use. The current draft doesn’t 
intend to answer the routing protocol issue. It was not left blank for the 
simple reason we  needed to implement it and make it run.


I think that's still an open question (determine which prefix to 
delete…), and an interesting side effect of a decision to split routing 
and prefix assignment.


e.g. looking at 
http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-06 
section 5.2


and especially considering any end hosts that do not understand 
http://tools.ietf.org/html/draft-troan-homenet-sadr-00,


do you want RA to start or stop advertising a prefix (hat has been 
derived from an upstream neighbor) on a local interface as a candidate 
default routeto locally connected end systems because the path to that 
ISP is down (routing), or because of a configuration timeout (DHCPv6 PD 
+ HNCP), or both, or neither?



I dont think we want to run a complex routing protocol in HNCP. It’s more like 
either we want to make something very simple, and we use HNCP for this, or we 
want all what you said, and we use another existing protocol. The point of the 
draft is just to let you know that it is *possible* to route packets, in a very 
simple way, by using just HNCP as it is, with no extra information.

Regards,
Pierre


--
Regards,
RayH

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







--
Regards,
RayH

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

Re: [homenet] WG adoption of draft-stenberg-homenet-hncp-00

[Ray Hunter]

Support adoption of HNCP as a WG item.

I am interested to read more information on how Homenet would/could work 
with zero routing protocol.


I presumed exactly one common Homenet interworking routing protocol.

Ray Bellis wrote:

At IETF 89 in London we took three hums:

1. On use of OSPF vs HNCP for configuration - strong consensus for HNCP

2. On how many routing protocols we should support in Homenet -
   strong consensus that it should be zero or one, but no consensus yet
   on which.

3. On adoption of HNCP as a WG item - good consensus for, a few undecided,
   none against.

On this basis the Chairs wish to proceed with the formal call for adoption of 
draft-stenberg-homenet-hncp-00, with a two week response window.

Please therefore send your comments on adoption of this draft to the list 
before 23:59 UTC on Tuesday 1st April.

thanks,

Ray and Mark



--
Regards,
RayH

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

Re: [homenet] DNSSEC and homenet

[Ray Hunter]

Mark Andrews wrote:

In message20140305102536.gd9...@mx1.yitter.info, Andrew Sullivan writes:

Mark,

On Wed, Mar 05, 2014 at 08:58:23PM +1100, Mark Andrews wrote:

a bit of flip flop but most of the time one is just On WiFi at home or

The point is that we're designing a protocol, and most of the time
won't be good enough to avoid support calls to the ISP help desk.  ISP
margins are thin enough that it would be a bad thing to build a
specification that encourages that even rarely.


This is a problem that is INDEPENDENT of DNSSEC when you are siging both
zones.   This is about there being two versions of the zone.


I really don't see this as being a issue in practice.  Just sign
the zone (all verisons) in the house with the same keys.  Stop with
this nonsence idea that you shouldn't sign the internal version
when you are signing the external version.

Mark, you're at least jumping ahead to implementation and at worst
begging the question.  We started with a proposal that did signing in
the ISP's server.  I was pointing out the consequences of that for
DNSSEC.  One of the possible solutions is that the internal version
is unsigned.  It would be careless not to list that as one of the
possibilities, even if I think that's a foolish outcome.  We have to
list the possibilities we don't like, too, or else we won't have a
clear picture of what we're talking about.


Signed and unsigned versions of the same zones are a REALLY REALLY
REALLY REALLY bad idea.

+1

  This is a Doctor it hurts if I do this.
Then don't do this. example. It could be made to work with negative
trust anchors which are installed when the WiFi SSID matches the
home's SSID but we really don't want to go there.  There be dragons.

It is dead simple for nameserver in the CPE to do the signing.  Why
people thing it is beyond the capabilities of the a device like
this is beyond me.  The CPE generated the keys.  It signs the
records.  It updates the parent zone to add DS records for the keys
it has generated.

The owner of the CPE has to do nothing to make this happen.

Either sign all version or don't sign any.

+1

I will appeal any version that even hints that mixed signing is the
way to go.  It is just bad design, bad engineer and will cause pain
for everyone.


Best regards,

A

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

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


--
Regards,
RayH

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

Re: [homenet] DNSSEC and homenet

[Ray Hunter]

Michael Richardson mailto:mcr+i...@sandelman.ca
4 March 2014 14:30
Ray Hunter v6...@globis.net wrote:
 On Tue, Mar 04, 2014 at 10:08:53AM +, Ralf Weber wrote:

 or on the ISP auth name server). I have no problem with signing on
 the CPE. I just don't want to make it mandatory

 For the purposes of this discussion, I'm going to assume that one has
 an inward-facing zone and and outward-facing one (i.e. this is a
 split-brain DNS situation).

 I think even large corporations are slowly learning that split-brain
 DNS is a bad idea that seemed like a good idea at the time, especially
 in the presence of highly-mobile devices, and forwarders.

 I'm becoming a convert myself to that way of thinking. That doesn't
 mean to say that we can't use 'views' or some other mechanism to hide
 some records from being resolvable from the outside.

The issue is that actually, you want some nodes to be able to resolve many
records even when they are outside.


Agreed. Cloud computing being a prime disruptor to the split brain model.

--
Michael Richardson mcr+i...@sandelman.ca, Sandelman Software Works
-= IPv6 IoT consulting for hire =-





--
Regards,
RayH

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

Re: [homenet] HNCP

[Ray Hunter]

Mark Townsley wrote:


All,

In case anyone missed it, Markus and Pierre posted drafts and a 
pointer to an implementation describing the Home Net Control Protocol.




Running code is very welcome.


I'd like to provide some additional background, hat off.

The work Markus, Stephen and Pierre have been doing is funded by a 
Cisco Technology Fund grant. The purpose of this grant has been to 
deliver technology backed by open source code that will be adopted by 
a community willing to maintain it, with the ultimate goal of that 
technology making its way into commercial product (for this to matter, 
it needs to make it into far more than Cisco product). During its 
first phase of operation, the main focus was on work originally 
started by Jari Arkko, Acee Lindem, and Benjamin Paterson in OSPF by 
fleshing this out in code and spec. Much was learned, and you may have 
seen some of the results at various bits-n-bytes and in draft updates 
(or the Markus' github if you were watching). The second phase, which 
began after the Berlin IETF, has been to take what was learned in the 
first phase and focus on:


- upstreaming the technology into an open source project (in this 
case, OpenWRT)

- modularity and adaptability to other routing protocols (e.g., ISIS)
- best-effort capabilities in simple topologies in case one common 
routing protocol support was not available
- integration with draft-behringer-homenet-trust-bootstrap 
and draft-kline-default-perimeter


The result after several months of heads-down effort is contained in 
the drafts below. The document from pfister is an evolution of the 
IPv6 prefix assignment work started by Jari, but in its own document 
such that it can be referenced by to OSPF, ISIS, HNCP, etc. The two 
from stenberg describe HNCP, as well as a general way to support 
Stuart's work in draft-cheshire-mdnsext-hybrid in a zeroconf mannter 
when the list of routers in a site is known (as HNCP does, or any 
link-state routing protocol should).


Personally, I was very skeptical when the team let me know that the 
result of their analysis led them to the need to create HNCP. If 
nothing else, between the OSPF work done in Phase one, and the HNCP 
work in Phase two, these are two concrete examples in draft and code 
form for the WG to examine to help decide the first question at the 
top of Ole's flowchart posted here earlier.


For those with no time to read the drafts, here's my one paragraph 
synopsis of what HNCP does:


HNCP uses the Trickle (RFC6206) algorithm to trigger when basic 
configuration state for the homenet is out of sync on any router. 
Essentially, a hash (or signature if security is present) over an 
ordered list of the known homenet nodes and attributes necessary to 
keep the homenet alive is handed over to Trickle. Trickle worries only 
about that hash value, and whether all nodes agree that the value is 
the same. When they don't agree, HNCP sends update messages between 
nodes until Trickle is happy again. The HNCP document also defines 
some specifics used in the OpenWRT implementation for border detection 
(based on draft-kline-homenet-default-perimeter), some hooks for 
integration with Behringer's trust bootstrapping (not 100% finished 
though), IPv4 and IPv6 prefix distribution, and an auto-negotiation 
mechanism depending on what type of routing protocol support is 
available. In the event no common routing protocol is available, HNCP 
defines a fallback mode that at least gets packets out the right 
interface and avoids loops, even if the path is not ideal, has no 
metrics, etc.


This is all pretty close to what the team set out to achieve with the 
4 bullets above as constraints and guidelines. Of this I can't help to 
be impressed. It came with a new protocol though, which shouldn't be 
taken lightly, but indeed might be necessary. I look forward to what 
the WG ultimately decides here.


Finally, if you want to follow some of the work being done by Markus, 
Stephen, Pierre, et. al. without necessarily logging into a github to 
do it, you can poke around here: http://www.homewrt.org (it may be a 
tad behind the latest-greatest though).


Hat back on now… Tim, Ray and I are working with the ADs to get the 
homenet-arch doc through the system. According to Tim, all DISCUSS 
points have been worked out on email with ADs weeks if not months ago, 
and the results are in -12 which has been posted. We're back to 
prodding ADs for time and mental cache reloading of their issues for 
them to clear. Once that is finished, the WG will finally be at a 
point that it can officially work on solutions.


Now, as Markus asked, Discuss! :-)

- Mark


Markus Stenberg markus.stenb...@iki.fi 
mailto:markus.stenb...@iki.fi (and Pierre Pfister) wrote:



Drafts:
http://tools.ietf.org/html/draft-stenberg-homenet-hncp-00


I have read this draft. Quotes below marked  are from the draft


 Is there a case for non-link-local unicast?
Not IMHO. That could be extremely 

Re: [homenet] Homenet protocol decisions

[Ray Hunter]

Lorenzo Colitti wrote:
On Thu, Jan 30, 2014 at 2:48 AM, Ole Troan otr...@employees.org 
mailto:otr...@employees.org wrote:


We need to decide, if we want prefix assignment and distribution
of other configuration information integrated in a routing protocol.


I think the two should be in the same protocol, because routing and 
addressing are tightly coupled. Fundamentally, there is no point in 
configuring an address on a host if the homenet doesn't have 
reachability to it - because you can't use that address to talk to 
anyone else in the homenet.


If the routing protocol and the prefix distribution protocol are 
separate, then they can end up with different ideas on what prefix is 
on a given link. That will lead to blackholing.

+1

I don't see how you're going to avoid tight coupling and still keep 
things stable when/if provider links and internal links flap.


IMHO there's got to be some form of fate sharing to avoid every single 
app having to implement a version of happy eyeballs.


--
Regards,
RayH

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

Re: [homenet] Naming and Service Discovery

[Ray Hunter]

 Ole Troan mailto:o...@cisco.com
 27 February 2013 08:51


 in a service discovery world, would you even care about what the
 phone's name is?
Theoretically fine, but in combination with autoconfig of links, the
domain names are also likely to be meaningless and changing, which means
service discovery becomes a must for all homenet nodes. And there's
the possibility of difficult to debug name clashes as myphone or
mygamestation moves between links. 
 does a name really have any meaning without a service associated with it?

URLs have meaning (rfc1738). It's going to be tough to know when your
browser (connecting from off-net) can cache
http://myphone.building1.isp1.com or not. Cookie handling too (keyed on
URL, which is hard linked to hostname, which will change when the phone
moves to http://myphone.building2.isp1.com).

Or is there some magic to handle this that scales to the whole Internet?

At least if just the IPv6 address changed we'd only have to deal with
caching hostname - IPv6 addresses lookups.
 let us assume that we don't want anyone to remember these names. the
 UI will present a list
 of available services, given where you are.

Right, but the FQDN changes every time a device moves, not just the
address, which either means large amounts of service discovery traffic
(like Appletalk ZIP/NBP + the Finder which had huge scaling issues),
or large amounts of update traffic plus potential caching issues of
anything linked to URL (and in turn to hostname).
 in that sense I really don't care what the domain name for my local
 link or site is either.
 internally I don't use them, for access into my home when I'm outside
 I need to type in the externally visible
 domain into my service discovery domain registry once.

 cheers,
 Ole
 Ray Hunter mailto:v6...@globis.net
 27 February 2013 08:35
 From the quoted draft: for the purposes of this document, assume that
 each link has its own unique Unicast DNS domain name,
 which I don't think is acceptable in Homenet. I don't want my phone's
 name to change when I walk out to the shed.
 

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

Re: [homenet] Naming and Service Discovery

[Ray Hunter]

Michael Thomas wrote:
 On 02/27/2013 12:46 AM, Ray Hunter wrote:

 [Ole] does a name really have any meaning without a service
 associated with it?

 [Ray] URLs have meaning (rfc1738). It's going to be tough to know
 when your
 browser (connecting from off-net) can cache
 http://myphone.building1.isp1.com or not. Cookie handling too (keyed on
 URL, which is hard linked to hostname, which will change when the phone
 moves to http://myphone.building2.isp1.com).
 [Mike] Allow me to poke at that assumption: why should we expect that
 the name (assuming there's only one, which is a bad assumption IMO),
 changes instead of the address record(s)? If I travel around with my
 toothbrush, shouldn't I expect it to remain named
 mikestoothbrush.mtcc.com?
 Perhaps it may update a local dns to
 mikestoothbrush.1027.holidayinn.com
 too, but if I really want to replenish its digital toothpaste, I'd almost
 certainly surf to https://mikestoothbrush.mtcc.com to make certain I'm
 not being tricked into resupplying ot.1027.holidayinn.com's toothbrush.


[Ray] Mike, your quoting in the above message was rather strange, so
I've tried to re clarify who wrote what.
[Ray] http://tools.ietf.org/html/draft-cheshire-mdnsext-hybrid-01 is
proposing that both the domain name and the IPv6 address change as nodes
move across subnets within homenet AFAICS.
[Ray] Changing domain names (and thus URL) when a device moves within
homenet is bad IMHO.
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] NPTv6-only home networks

[Ray Hunter]

Michael Thomas wrote:
 On 02/26/2013 09:10 AM, Ray Hunter wrote:

 , but what if there are two edge routers?

 Elect one to be authoritative: which needs a new protocol, plus some
 really complex take-over mechanism on failure.

 Pardon my ignorance, but how does this happen in real life, and in
 particular with anycast? Aren't all of the anycast reachable servers
 authoritative as far as the outside world is concerned?

 Mike

As far as I can see, there are no existing off-the-shelf solutions
available that cover all homenet naming requirements.

Therefore to answer your question: it doesn't happen in real life today.

We're talking theoretical auto-config of DNS servers by some process.
Which would be new and require some sort of election protocol to see
which CER would become the anointed one. That server would then have
to work out which zone(s) to serve, given multiple parent ISPs. Also if
it failed we'd have to start all over again.

Hence the alternative suggestion that all CERs could always become
authoritative DNS servers, each providing a zone delegated from their
respective parent ISP (or other DNS name service provider). We'd
probably then either have to suggest the end nodes update all the
servers present in the homenet actively with name- information via
registration every time they moved. Or perhaps more practically, get the
host to update a random CER somehow, and then work out some way of
mirroring the latest info between zones in the background between the
CERs, without needing a static master-slave relationship. That'd
probably also require some new stuff.

But I'd still rather look at the gap analysis to make DNS work (with new
autoconfig/mirroring stuff), than try to proxy mDNS over multiple
subnets in an arbitrary topology (messy), or extend mDNS to be
multi-subnet aware (completely new, and reliant on site-wide multicast),
or extend a stateless protocol like mDNS to update DNS for off-homenet
resolution.
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Egress Routing Discussion: Baker model

[Ray Hunter]

 Lorenzo Colitti mailto:lore...@google.com
 25 February 2013 09:47
 On Mon, Feb 25, 2013 at 5:25 PM, Ray Hunter v6...@globis.net
 mailto:v6...@globis.net wrote:

 Figure 2 of the architecture is the problematic one, where there
 are end
 hosts that share the only connection between 2 CERs (from
 competing ISPs).

 The end hosts do not share the same information as the 2 routers
 (the end hosts ignore routing, and the PIO sent by the 2 CERs are
 non-overlapping, as they are configured by 2 independent ASs).


 Maybe I don't understand the problem. 

 You're talking about the figure in
 http://tools.ietf.org/html/draft-ietf-homenet-arch-07#section-3.2.2.2
 , right? And your concern is: what happens if H1 sends a packet with
 source address SA (assigned from ISP A) to CER2?
yes. Bigger concern is that the borders of Homenet seem fuzzy, but I've
expressed that elsewhere.

 The answer is that at CER2, the packet will not match the default
 route to ISP B because the source address doesn't match. However, it
 matches the default route to ISP A announced by CER1. So CER2 forwards
 the packet to CER1, and CER1 sends it out to ISP A. Yes, it's an extra
 IP hop, but the packet gets to where it needs to go. No?

Thanks.

That'd work (provided your draft updates/clarifies RFC2461 Section 8.2
to cover SADR so an ICMP redirect is not sent in this case, and provided
BCP38 filters of RFC6204 requirement S-2 have been applied to the WAN
interface, not the LAN).

It would also seem to suggest that if CER1 and CER2 LAN interfaces are
within the homenet boundary, that if the WAN link to CER2 failed, then
CER2 would also learn a default route from CER1 (and vice versa), and
any telephony traffic or management traffic generated by CER2 would also
be sent to CER1 and ISP1 if it had a source address of ISP1?

Suggesting ISP specific services and applications should only bind to
source addresses native to their own ISP?

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

Re: [homenet] Working Group Last Call for draft-ietf-homenet-arch-07

[Ray Hunter]

As requested I have read draft-ietf-homenet-arch-07. Thanks everyone for
the effort so far.

IMHO I think the document is in very good shape, but that we're not
quite there yet
(which I guess means I'm obliged to supply comments on why I think
that's the case).

The main thrust of my comments below is an underlying feeling that we
haven't yet fully got a handle on the boundary at the ISP/customer
interface  the homenet/Internet interface, and that this will bite us
later.

I also think there's quite a bit of room to tighten up on nomenclature.
e.g. home network v. homenet. ISP uplink v. Customer Internet
connections. Border v. CER v. Border CER.

Perhaps rather surprisingly, homenet is not defined anywhere.

regards,
RayH

Detailed comments
===

Section 1
s/While at the time of writing some complex home network topologies
exist, but most are/
While at the time of writing some complex home network topologies exist,
most are /

s/like to avoid such/like to avoid, such/

s/IPv6 with an eye/IPv6, with an eye/

s/can not be affected by new /cannot be modified by new /


/[RFC6204] defines basic requirements for customer edge routers
   (CERs).  The scope of this text is the internal homenet, and thus
   specific features on the CER are out of scope for this text./

I find this particular formulation confusing.

Perhaps
/[RFC6204] defined basic requirements for customer edge routers (CERs),
which has recently been updated with the definition of requirements for
specific transition tools on the CER in RFC 6204-bis
[I-D.ietf-v6ops-6204bis] i.e. DS-Lite [RFC6333] and 6rd [RFC5969]. Such
detailed specification of CER devices is considered out of scope of this
architecture document, and we assume that any required update of the CER
device specification as a result of adopting this architecture will be
handled as separate and specific updates to these existing documents./

Section 1.1.
/CER: Customer Edge Router.  A border router at the edge of the homenet./

I regularly read Homenet BR or Border Router on this list used
interchangeably with CER.
Are they different? Equivalent? Or do we need to change our
behaviour/definitions?

This is my biggest worry. Do we have a good handle on the interface at
the border?

Does the set of End-User network(s) in Section 3 map 1:1 with a homenet?
I don't think so: it includes the CER.

What is a Service Provider Network? The rest of the Internet that
isn't in the homenet?
Wouldn't harm to copy some more definitions from 6204.

Section 2.1

s/This is discussed later in the document./This is discussed in Section
3.7./

/border router(s)/
See comment on 1.1 Border Router v Customer Edge Router?


/There will also be the need to discover which routers in the homenet
   are the border router(s) by an appropriate mechanism.  Here, there
   are a number of choices.  These include an appropriate service
   discovery protocol, or the use of a well-known name, resolved by some
   local name service.  Both might have to deal with handling more than
   one router responding in multihomed environments./

Above paragraph does not make sense to me.
Seems to be a context shift in the middle of the paragraph.
How is a name service related to discovery of a border router?
We're not suggesting all CER's have to be called a particular hostname?

/2.2.  Global addressability and elimination of NAT/
Strictly speaking, NAT won't be eliminated entirely. IPv4 will still use
NAT. IPv6 never had NAT.
How about just /2.2.  Global addressability/

s/The end-to-end communication that is potentially enabled with IPv6/
The possibility for direct end-to-end communication on the Internet that
will be restored by the introduction of IPv6/

The Internet architecture always was, and still is, direct end-to-end
communication. We just temporarily lost the ability to do it due to lack
of addresses.


s/on the firewall/
on any firewall/


Section 2.3
s/Default Address Selection for IPv6[I-D.ietf-6man-rfc3484bis]/
Default Address Selection for Internet Protocol Version 6 (IPv6) [RFC6724]/

s/We discuss such challenges in multihoming later in this document./
We discuss such challenges of multihoming in Section 3.3.1./

Section 2.4
s/Despite this counter-argument, while setting a network up there may be
a period with no connectivity/
/pDespite this counter-argument, there may be a period with no
connectivity while setting up a network/

s/when the ULA destination lies within a /48 ULA prefix known to be used
within the same homenet./
when the ULA source and destination addresses lie within a single /48
ULA prefix known to be used within the same homenet.
However, it should be noted that even if it were known that multiple /48
ULA prefixes are in use within a single homenet
(perhaps because multiple homenet routers each independently
auto-generate a /48 ULA prefix and then share routing information),
utilising a ULA source address and a ULA destination address from two
disjoint /48 ULA prefixes is not preferred 

Re: [homenet] Egress Routing Discussion: Baker model

[Ray Hunter]

I have read all of your drafts, and those of the other authors,
carefully, once. No doubt I'll have to re-read them.

This response is limited to high level comments regarding the overall
approach, and isprobably applicable to all 3 sets of authors :

1. Some drafts talk extensively about the need for an extensible
routing protocol, and often mention the desirability of TLV
(type-length-value) objects.

I agree that a TLV structure potentially solves many issues of how to
encode and transport new options between routing protocol speakers.

But given that route determination is a distributed algorithm, and that
Homenet devices will not always run the latest and greatest code,
what action should nodes that are running older code take regarding any
TLV options that they don't understand?

Isn't there a danger that extensibility will lead to more routing loops,
instability, and black holes?

Is there a need for all speakers to first agree the (newest)
commonly-understood subset of options that all speakers in a Homenet
can/will honour before any extension options are transmitted?

2. Aren't we forgetting the first hop?

Given a shared subnet/prefix/link with 2 CPE routers performing some
fancy new form of forwarding (based on PBR or SADR or whatever) that is
also shared by existing host implementations, how will the routers
signal these new default route semantics to end hosts?

Would we need a new prefix information option in ND?

Would we need an extension to RFC 4191 Section 2.3 Route Information
Option to include (source prefix,destination prefix) routes?

Would we need a new ICMPv6 redirect message to extend RFC2461 Section
4.5 to include the possibility of (source,destination) redirects?

3. Limiting this discussion strictly to Homenet requirements:  Aren't we
forgetting the inter-provider management boundary?

My view of the Homenet is a network that is potentially a member of
multiple overlapping AS's simultaneously, without being an AS itself.
That's highly unusual in routing protocol terms.

I think that it is very unlikely that any operator will allow any
dynamic routing between a CPE managed by a customer and a PE managed by
the provider.

I think there's also a potential issue of anyone making any assumptions
about dynamic routing being available between a provider-managed CPE and
a customer owned CPE. Software version control will not be trivial.

The current most likely source of external routing information is
DHCPv6-PD, used to locally autoconfigure a floating static default
route on the Homenet BR, pointing out of the upstream interface to the
Internet.

As such, how will any routing information beyond a simple default route
(related to a single delegated prefix) be injected into the Homenet?

Why are we importing the extra complexity (related to data centres and
enterprises) into Homenet?

4. We're still planning on doing something about source address
selection, aren't we?
For all the suggested complexity of the packet routing solutions
suggested so far, isn't the real route selection going to be performed
in the host?

5. Flow label routing: hasn't rfc6437 scuppered any chance that the flow
labels themselves will directly carry any meaning that could be
realistically used to make deterministic forwarding decisions by
low/mid-powered routers, because you're essentially going to have to
reverse a 20 bit hash function to make a forwarding decision? Wouldn't
the requirements in rfc6437 also suggest a routing table explosion,
because each individual flow would have to be associated with an
individual IS-IS route? Perhaps you could distribute some intermediate
result to end hosts and routers via IS-IS,which is deterministic and
related to policy based routing (such as including the tenant label in a
TLV), but which after applying some hash transform and adding some
entropy, would comply with the requirements of 6437? That'd potentially
reduce the IS-IS routing table size dramatically. I've been waiting 15+
years for fully dynamic PBR and I fully expect to wait some time longer.
In any case, with all due respect, I don't think it's relevant for Homenet,

6. Other potentially simpler approaches that might be faster to market
I have provided detailed feedback to Ole  Lorenzo, suggesting how
Homenet could potentially work without modifying any routing protocols
at all, with multi-homing, without resorting to NPT, and with BCP38
ingress/egress filters (albeit with a hard link to some
yet-to-be-defined autoconfiguration protocol, and a limit that the
prefixes of any walled-gardens must be disjoint from other AS's directly
connected to this Homenet, and possibly some other limitations such as
dumb hosts should not be connected to dual routers from competing
providers).

Do I need to write a draft on this, or is this already clear?
Would someone be willing to help out/ collaborate?

If I have other detailed comments on the individual drafts, I'll come
back with those.

regards,
RayH

Fred Baker (fred) 

Re: [homenet] Egress Routing Discussion: Baker model

[Ray Hunter]

 Lorenzo Colitti mailto:lore...@google.com
 22 February 2013 11:17
 On Fri, Feb 22, 2013 at 6:52 PM, Ray Hunter v6...@globis.net
 mailto:v6...@globis.net wrote:

 But given that route determination is a distributed algorithm, and
 that
 Homenet devices will not always run the latest and greatest code,
 what action should nodes that are running older code take
 regarding any
 TLV options that they don't understand?

 Isn't there a danger that extensibility will lead to more routing
 loops,
 instability, and black holes?


 Yes. If intermediate devices don't understand SADR, you can get
 routing loops. We should document that clearly and find out how to
 avoid it.
  
ACK.

 2. Aren't we forgetting the first hop?

 Given a shared subnet/prefix/link with 2 CPE routers performing some
 fancy new form of forwarding (based on PBR or SADR or whatever)
 that is
 also shared by existing host implementations, how will the routers
 signal these new default route semantics to end hosts?

 Would we need a new prefix information option in ND?

 Would we need an extension to RFC 4191 Section 2.3 Route Information
 Option to include (source prefix,destination prefix) routes?

 Would we need a new ICMPv6 redirect message to extend RFC2461 Section
 4.5 to include the possibility of (source,destination) redirects?


 The beauty of this approach is that you don't need to signal anything
 to the hosts for things to work properly. The hosts pick whatever
 source address they choose and the network takes care of getting the
 packet to the right exit.

Don't understand. Maybe I'm being really dumb.

What about figure 2 of the Homenet Architecture? fixed width

   +---+---+ +---+---+ \
   |   Service | |   Service |  \
   |  Provider A   | |  Provider B   |   | Service
   |Router | |Router |   | Provider
   +--++ +---+---+   | network
  |  |   /
  |  Customer|  /
  | Internet connections | /
  |  |
   +--++ +---+---+ \
   | IPv6  | |IPv6   |  \
   | Customer Edge | | Customer Edge |   \
   |   Router 1| |   Router 2|   /
   +--++ +---+---+  /
  |  | /
  |  || End-User
 ---+-+---+---+--+--+---  | network(s)
| |   | |  \
   ++-+ +-++ ++-+ +-++  \
   |IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host |  /
   |   H1 | |   H2 | |H3| |H4| /
   +--+ +--+ +--+ +--+

 Figure 2

/fixed width

IPv6 Host H1 will receive RA messages from R1 and R2, and add them both
to the default router list (RFC2461 6.3.6).

IPv6 Host H1 will receive two PIO's, one each from R1 and R2, with
autoconfiguration and on-link flags set, and configure /64 prefixes from
both provider 1 and provider 2 (RFC 2461 4.6.2) and it will know these
as being on-link.

But IMHO there's no further AS number/provider information/upstream
topology information coupled to these /64 prefixes. There might be a
router-router interconnect LAN between R1 and R2, or there might not be.

How will the host H1 know to associate source address prefixes from
provider2 with router2 for off link destinations e.g. to a Provider2/56
or Provider2/32?

My expected host behavior would currently be that it'd just choose one
of the known available default routers from the list. If correct fine.
If not, then wait for an ICMPv6 redirect to be told to use the other router.

But the ICMPv6 redirect doesn't have any facility to include source
prefix specific info: only a redirect for a destination prefix to use
another router (for all source prefixes), not for a source/destination
pair. In the situation depicted in Homenet Arch figure 2, there will
almost certainly be two valid routes to e.g. www.google.com, one via
each provider, with the correct 1st hop router dependent purely on the
source prefix.

Even with RFC4191, the extension only provides routing information for a
host to be able to select a default router based on the destination
prefix, not an associated source prefix.

Are we saying that H1 should tightly couple source address selection
with RA PIO  default router selection?

Thus H1 should never send packets with a source address derived from a
PIO received in an RA from R2, to a potential default router R1 that
sent an RA

Re: [homenet] Fwd: New Version Notification for draft-troan-homenet-sadr-00.txt

[Ray Hunter]

   could be the point where the real routing decision is
made, whilst SADR would be used to select the correct Homenet BR and to
avoid the ingress filters once the correct source address has been decided.

regards,
RayH

 cheers,
 Ole
 Ray Hunter mailto:v6...@globis.net
 20 February 2013 08:46
 I have read this draft and find it useful.

 A routing entry may have both  (S, D) paths and (*, D) paths.  The
 longest match wins

 Section 5 seems to suggest SADR is just a tie breaker applied to the
 subset of equal length D routes, but I think you probably should be more
 specific on the phrase longest match in this sentence, as there are 2
 length comparisons (one on D and one on S)

 Section 6.2.

 During autoconfig, if the prefix is delegated to other Homenet routers
 on a hop by hop basis, the Homenet router receiving a new prefix could
 indeed install a default SADR route for (parent_prefix/x,0:/0) - the
 upstream delegating router. So in this case your requirement 2 to
 strongly couple autoconfiguration  and routing would not seem onerous.

 But alternatively, if the delegation of prefixes within Homenet occurs
 via a mechanism like DHCP PD, the receiving router could instead install
 a default SADR route (parent_prefix/x,0:/0) - Homenet BR DHCP PD source
 address, and then recurse the standard unicast routing table to find the
 appropriate next hop toward the Homenet BR. This is a trick that works
 very well in BGP networks (with next BGP hop being a software/loopback
 interface of the AS egress router that is always up and stable, combined
 with an IGP containing just the loopback addresses of the BGP speaking
 AS egress routers)

 In which case there's no requirement for a hard link between the routing
 protocol and the prefix autoconfiguration mechanism, and thus no
 requirement to update the IGP to carry SADR routes, which I think is
 potentially a big win.

 regards,
 RayH

 Ole Troan wrote:
 Begin forwarded message:

 From: internet-dra...@ietf.org
 Subject: New Version Notification for draft-troan-homenet-sadr-00.txt
 Date: February 18, 2013 22:01:47 GMT+01:00
 To: o...@cisco.com
 Cc: lore...@google.com
 Received: from mail.cisco.com [173.36.12.72] by otroan-mac.getinternet.no 
 with POP3 (fetchmail-6.3.20) for otroan@localhost (single-drop); Mon, 18 
 Feb 2013 22:02:13 +0100 (CET)
 Received: from rcdn-iport-6.cisco.com (173.37.86.77) by mail.cisco.com 
 (173.36.12.81) with Microsoft SMTP Server (TLS) id 14.2.318.4; Mon, 18 Feb 
 2013 15:01:50 -0600
 Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by 
 rcdn-iport-6.cisco.com with ESMTP; 18 Feb 2013 21:01:49 +
 Received: from rcdn-inbound-i.cisco.com (rcdn-inbound-i.cisco.com 
 [72.163.7.178])   by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id 
 r1IL1ixR029679   for o...@cisco.com; Mon, 18 Feb 2013 21:01:49 GMT
 Received: from mail.ietf.org ([64.170.98.30]) by rcdn-inbound-i.cisco.com 
 with ESMTP; 18 Feb 2013 21:01:49 +
 Received: from localhost (localhost [127.0.0.1])by ietfa.amsl.com 
 (Postfix) with ESMTP id CA4D221F8C03; Mon, 18 Feb 2013 13:01:48 -0800 (PST)
 Received: from mail.ietf.org ([64.170.98.30])   by localhost 
 (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 
 IlwPsnRC5mQw; Mon, 18 Feb 2013 13:01:48 -0800 (PST)
 Received: from ietfa.amsl.com (localhost [127.0.0.1])   by 
 ietfa.amsl.com (Postfix) with ESMTP id EA73121F8C56; Mon, 18 Feb 2013 
 13:01:47 -0800 (PST)
 Authentication-Results: rcdn-inbound-i.cisco.com; dkim=utral (message not 
 signed) header.i=none
 X-From-Outside-Cisco: 64.170.98.30
 X-Ironport-Anti-Spam-Filtered: true
 X-Ironport-Anti-Spam-Result: 
 Ak0BAE6WIlFAqmIemWdsb2JhbABEhkmoGgGRP4EFFg4BAQEBAQgLCwcUJ4JJVAI1AiYCSTKICQyuZJIogSONfxUdgheBEwOIZ41EAYEdkmM
 X-Ironport-Av: E=phos;i=4.84,690,1355097600; d=scan'208;a=89740088
 X-Virus-Scanned: amavisd-new at amsl.com
 Content-Type: text/plain; charset=tf-8
 Content-Transfer-Encoding: quoted-printable
 X-Test-Idtracker: no
 X-Ietf-Idtracker: 4.40
 Message-Id: 20130218210147.7330.45442.idtrac...@ietfa.amsl.com
 Return-Path: internet-dra...@ietf.org
 X-Ms-Exchange-Organization-Authsource: xhc-aln-x07.cisco.com
 X-Ms-Exchange-Organization-Authas: Internal
 X-Ms-Exchange-Organization-Authmechanism: 10
 Mime-Version: 1.0


 A new version of I-D, draft-troan-homenet-sadr-00.txt
 has been successfully submitted by Ole Troan and posted to the
 IETF repository.

 Filename:draft-troan-homenet-sadr
 Revision:00
 Title:   IPv6 Multihoming with Source Address Dependent Routing 
 (SADR)
 Creation date:   2013-02-18
 Group:   Individual Submission
 Number of pages: 7
 URL: 
 http://www.ietf.org/internet-drafts/draft-troan-homenet-sadr-00.txt
 Status:  http://datatracker.ietf.org/doc/draft-troan-homenet-sadr
 Htmlized:http://tools.ietf.org/html/draft-troan-homenet-sadr-00


 Abstract:
   A multihomed network using provider aggregatable addresses must send
   the packet

Re: [homenet] Fwd: New Version Notification for draft-troan-homenet-sadr-00.txt

[Ray Hunter]

 Ole Troan mailto:otr...@employees.org
 20 February 2013 14:58
 Ray,

 thinking out loud.

 the border router includes in the advertisement of the aggregate prefix:
 - it's own global IPv6 address
 - list of external routes

 each internal router:
 - installs (S,D) routes for all of the external routes with the
 border's global as next-hop.

 normal unicast routing is used to get to the border.

 yep, that should work too. and be completely independent of routing
 protocol.
Agreed.
 but at the cost of being dependent on the prefix assignment mechanism.
True. Which anyway has still to be solved for Homenet.
 leaving the question open I suppose, does SADR have a wider
 applicability outside of the home network...

Almost certainly, if you believe in stateful firewalls, and multiple
alternate paths, but do not want to deploy either NAT66 or rfc6296
Network Prefix Translation (to guarantee a symmetric return path).

You could consider an approach like the CIDR RFC, split into 3 topics:
1) Semantics of making a forwarding decision given a SADR table
2) Considerations for (routing) protocols that maintain the SADR table
3) Homenet specific solution (potentially tied to prefix autoconfiguration)
 cheers,
 Ole
 Ray Hunter mailto:v6...@globis.net
 20 February 2013 11:06
 Ole Troan mailto:otr...@employees.org
 20 February 2013 09:59
 Ray,

 I have read this draft and find it useful.

 A routing entry may have both  (S, D) paths and (*, D) paths.  The
 longest match wins

 Section 5 seems to suggest SADR is just a tie breaker applied to the
 subset of equal length D routes, but I think you probably should be more
 specific on the phrase longest match in this sentence, as there are 2
 length comparisons (one on D and one on S)
 yes, right now we say:

First a longest match lookup is done in the routing table for the
destination address, then for the resulting set a longest matching
lookup is done for the source address.

 what if we also included some RIB entry examples?
 e.g.

 ::/0 (route)
   2001:db8::/56 - NH1 (path #1)
   2001:db9::/56 - NH2 (path #2)
   - NH#3 (path #3)

 would that make it clearer?
 Yes I think so. It's just a readability thing.

 Suggest including various combinations e.g. (*,::/0) 
 (2001:db8:1::/56,::/0)  (*,2001:db8:2::/56) 
 (2001:db8:1::/56,2001:db8:2::/56)
 Section 6.2.

 During autoconfig, if the prefix is delegated to other Homenet routers
 on a hop by hop basis, the Homenet router receiving a new prefix could
 indeed install a default SADR route for (parent_prefix/x,0:/0) - the
 upstream delegating router. So in this case your requirement 2 to
 strongly couple autoconfiguration  and routing would not seem onerous.
 right, in that case the parent prefix wouldn't really be the aggregate 
 prefix though, and not
 identify the border exit. in a strict routed hierarchy then I guess you 
 wouldn't need SADR.
 I don't see why it would not include this info. AFAIK we haven't yet
 settled on a prefix delegation mechanism, so the mechanism could carry
 both the aggregate prefix as well as the parent prefix at this point in
 the hierarchy, and even the border exit id/address. But then we're
 pretty much getting into a combined routing protocol and delegation
 mechanism exactly as you already indicated.
 But alternatively, if the delegation of prefixes within Homenet occurs
 via a mechanism like DHCP PD, the receiving router could instead install
 a default SADR route (parent_prefix/x,0:/0) - Homenet BR DHCP PD source
 address, and then recurse the standard unicast routing table to find the
 appropriate next hop toward the Homenet BR. This is a trick that works
 very well in BGP networks (with next BGP hop being a software/loopback
 interface of the AS egress router that is always up and stable, combined
 with an IGP containing just the loopback addresses of the BGP speaking
 AS egress routers)
 yes, now we tie the aggregate prefix and the advertising border router using 
 the router-id.
 if the border router had a global address, that was included in the 
 aggregate route advertisement
 as well as the external route advertisements, we could use that instead.
 Right. Why wouldn't a border router have a global address if it is
 connected to the Internet?
 Am I missing something?
 it would certainly make the routing tables more clearer and more explicit.
 And possibly converge faster too on local topology changes.
 In which case there's no requirement for a hard link between the routing
 protocol and the prefix autoconfiguration mechanism, and thus no
 requirement to update the IGP to carry SADR routes, which I think is
 potentially a big win.
 that would be a big win, but I don't quite see how you avoid the hard link?
 Thinking about this some more, it's specifically the requirement to
 select and modify a single IGP that is bothering me. That seems to make
 a big assumption about the autoconfiguration mechanism that we have yet
 to choose.

 Although that in the end modified OSPFv3

Re: [homenet] Fwd: New Version Notification for draft-troan-homenet-sadr-00.txt

[Ray Hunter]

I have read this draft and find it useful.

 A routing entry may have both  (S, D) paths and (*, D) paths.  The
longest match wins

Section 5 seems to suggest SADR is just a tie breaker applied to the
subset of equal length D routes, but I think you probably should be more
specific on the phrase longest match in this sentence, as there are 2
length comparisons (one on D and one on S)

Section 6.2.

During autoconfig, if the prefix is delegated to other Homenet routers
on a hop by hop basis, the Homenet router receiving a new prefix could
indeed install a default SADR route for (parent_prefix/x,0:/0) - the
upstream delegating router. So in this case your requirement 2 to
strongly couple autoconfiguration  and routing would not seem onerous.

But alternatively, if the delegation of prefixes within Homenet occurs
via a mechanism like DHCP PD, the receiving router could instead install
a default SADR route (parent_prefix/x,0:/0) - Homenet BR DHCP PD source
address, and then recurse the standard unicast routing table to find the
appropriate next hop toward the Homenet BR. This is a trick that works
very well in BGP networks (with next BGP hop being a software/loopback
interface of the AS egress router that is always up and stable, combined
with an IGP containing just the loopback addresses of the BGP speaking
AS egress routers)

In which case there's no requirement for a hard link between the routing
protocol and the prefix autoconfiguration mechanism, and thus no
requirement to update the IGP to carry SADR routes, which I think is
potentially a big win.

regards,
RayH

Ole Troan wrote:
 Begin forwarded message:

 From: internet-dra...@ietf.org
 Subject: New Version Notification for draft-troan-homenet-sadr-00.txt
 Date: February 18, 2013 22:01:47 GMT+01:00
 To: o...@cisco.com
 Cc: lore...@google.com
 Received: from mail.cisco.com [173.36.12.72] by otroan-mac.getinternet.no 
 with POP3 (fetchmail-6.3.20) for otroan@localhost (single-drop); Mon, 18 
 Feb 2013 22:02:13 +0100 (CET)
 Received: from rcdn-iport-6.cisco.com (173.37.86.77) by mail.cisco.com 
 (173.36.12.81) with Microsoft SMTP Server (TLS) id 14.2.318.4; Mon, 18 Feb 
 2013 15:01:50 -0600
 Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by 
 rcdn-iport-6.cisco.com with ESMTP; 18 Feb 2013 21:01:49 +
 Received: from rcdn-inbound-i.cisco.com (rcdn-inbound-i.cisco.com 
 [72.163.7.178])by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id 
 r1IL1ixR029679   for o...@cisco.com; Mon, 18 Feb 2013 21:01:49 GMT
 Received: from mail.ietf.org ([64.170.98.30]) by rcdn-inbound-i.cisco.com 
 with ESMTP; 18 Feb 2013 21:01:49 +
 Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com 
 (Postfix) with ESMTP id CA4D221F8C03; Mon, 18 Feb 2013 13:01:48 -0800 (PST)
 Received: from mail.ietf.org ([64.170.98.30])by localhost 
 (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 
 IlwPsnRC5mQw; Mon, 18 Feb 2013 13:01:48 -0800 (PST)
 Received: from ietfa.amsl.com (localhost [127.0.0.1])by 
 ietfa.amsl.com (Postfix) with ESMTP id EA73121F8C56; Mon, 18 Feb 2013 
 13:01:47 -0800 (PST)
 Authentication-Results: rcdn-inbound-i.cisco.com; dkim=utral (message not 
 signed) header.i=none
 X-From-Outside-Cisco: 64.170.98.30
 X-Ironport-Anti-Spam-Filtered: true
 X-Ironport-Anti-Spam-Result: 
 Ak0BAE6WIlFAqmIemWdsb2JhbABEhkmoGgGRP4EFFg4BAQEBAQgLCwcUJ4JJVAI1AiYCSTKICQyuZJIogSONfxUdgheBEwOIZ41EAYEdkmM
 X-Ironport-Av: E=phos;i=4.84,690,1355097600; d=scan'208;a=89740088
 X-Virus-Scanned: amavisd-new at amsl.com
 Content-Type: text/plain; charset=tf-8
 Content-Transfer-Encoding: quoted-printable
 X-Test-Idtracker: no
 X-Ietf-Idtracker: 4.40
 Message-Id: 20130218210147.7330.45442.idtrac...@ietfa.amsl.com
 Return-Path: internet-dra...@ietf.org
 X-Ms-Exchange-Organization-Authsource: xhc-aln-x07.cisco.com
 X-Ms-Exchange-Organization-Authas: Internal
 X-Ms-Exchange-Organization-Authmechanism: 10
 Mime-Version: 1.0


 A new version of I-D, draft-troan-homenet-sadr-00.txt
 has been successfully submitted by Ole Troan and posted to the
 IETF repository.

 Filename: draft-troan-homenet-sadr
 Revision: 00
 Title:IPv6 Multihoming with Source Address Dependent Routing 
 (SADR)
 Creation date:2013-02-18
 Group:Individual Submission
 Number of pages: 7
 URL: 
 http://www.ietf.org/internet-drafts/draft-troan-homenet-sadr-00.txt
 Status:  http://datatracker.ietf.org/doc/draft-troan-homenet-sadr
 Htmlized:http://tools.ietf.org/html/draft-troan-homenet-sadr-00


 Abstract:
   A multihomed network using provider aggregatable addresses must send
   the packet out the right path to avoid violating the provider's
   ingress filtering.  This memo suggests a mechanism called Source
   Address Dependent Routing to solve that problem.




 The IETF Secretariat



___
homenet mailing list
homenet@ietf.org

Re: [homenet] I-D Action: draft-ietf-homenet-arch-05.txt

[Ray Hunter]

Tim Chown wrote:
 Hi all,

 The architecture text has been updated to -05.

 See: http://tools.ietf.org/html/draft-ietf-homenet-arch-05

 We can take comments towards a -06 over the weekend.  The most
 substantial changes are in the Naming and Service Discovery section
 (3.7), so if you have limited time please focus your reading there.

Thanks for editing this, Tim.

As requested, comments towards -06

Substantive Comments


Section 2.1

/The addition of routing between subnets raises the issue of how to
extend mechanisms such as service discovery which currently rely on
link-local addressing to limit scope. There are two broad choices;
extend existing protocols to work across the scope of the homenet, or 
introduce proxies for existing link layer protocols./

I think there is a viable third choice: Take existing (heavyweight)
Internet protocols, like DNS and OSPF, that already scale to cover large
routed infrastructures, and attempt to reduce the amount of expert
configuration required so that they are suitable for use in networks
that do not enjoy expert management.

By the time we've invented proxies and gateways from current mDNS to LLN
and Internet DNS, we may well end up spending more effort on two-way
name-space content synchronisation than we'd ever imagine.

Section 2.4

Use of ULA should probably also mention the following challenge:

Selecting a suitable prefix for use with an address scheme based on ULA
also presents a challenge when multiple routers are present. The default
source and destination address selection rules of [RFC6724] only provide
priority of ULA over GUA within a single /48 ULA prefix. If ULA is to be
preferred over GUA and multiple routers are present in the home network,
either the routers will have to co-ordinate selection of a single /48
ULA prefix for use across the entire home network, or all end nodes and
routers will have to receive delegated prefixes from each of the union
all /48 ULA prefixes in use in the home network, or a non-default
address selection policy will have to be distributed to all end nodes in
the home network e.g. via [draft-ietf-6man-addr-select-opt-06]

Section 2.6.

/ Ensuring there is a way to access content in the IPv4 Internet. This
can be arranged through appropriate use of NAT64 [RFC6144] and DNS64
[RFC6145], for example, or via a node-based DS-Lite [RFC6333] approach./

Can of worms. Out of scope. Long term there will be no IPv4, or IPv4
gateway may be outside of Homenet. Suggest deleting the DNS64 text.


Section 3.0

Is zero config a serious requirement? I just replaced a faulty ADSL2+
modem/ router. There's loads of config in there for ATM VC's etc. All I
had to do was go to a web page and select my provider from a drop down
list. Minimal config and wizard config seems good enough for me and for
existing products.

s/as far as possible, be self-configuring./as far as possible, be
self-configuring, or manual configuration should be kept to a minimum,
and possibly aided by user-friendly wizard configuration tools./

Section 3.3.1

3 realms gives 3 borders.

s/ then the borders will include that from the homenet to the ISP, and
that from the homenet to a guest network./ then the borders will include
that from
   the homenet to the ISP,that from the guest network to the ISP, and
that from the homenet to a guest network./


Section 3.4.1

/ ULAs should be used within the scope of a homenet to support routing
between subnets regardless of whether a globally unique ISP-provided
prefix is available./

Do we have sufficient knowledge of the current state of play of ULA
implementations running in parallel with GUA to be able to make this a
should? Personally, I'd be perfectly happy with a GUA address scheme
as long as my provider gave me DHCP-PD lease times that were an order of
magnitude longer than any typical outage (say a week compared to a one
day's down-time). On the other hand ULA-only operation should definitely
be supported in stand-alone homenets.

Section 3.4.4

/ In cases where two /48 ULAs are generated within a homenet, the
network should still continue to function./ In cases where two /48 ULAs
are generated within a homenet, the network should still continue to
function, meaning that both ULA prefixes should be used for delegation
throughout the homenet./

Section 3.5.1
IPv4 is out of scope.

s/In IPv4 NAT networks, the NAT provides an implicit firewall function.
[RFC4864] describes a Simple Security model for IPv6
networks,/[RFC4864] describes a Simple Security model for IPv6 networks,/

s/RFC 4864 implies an IPv6 default deny policy for inbound connections
be used for similar functionality to IPv4 NAT./RFC 4864 implies an IPv6
default deny policy for inbound connections./

s/It should be noted that such a default deny approach would
effectively replace the need for IPv4 NAT traversal protocols with a
need to use a signalling protocol to request a firewall hole be
opened./It should be noted that such a default 

Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00

[Ray Hunter]

I have read the draft and don't see how it advances Homenet.

IMHO If an MSP wants to deploy some tunnel brokers on the Internet to 
terminate what boils down to a pair of GRE tunnels, they can do so 
without the IETF providing any new standards work, and it'll all work 
just fine.


I'd prefer it if people concentrated on 
http://www.ietf.org/id/draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-04.txt


regards,
RayH

Damien Saucez wrote:

Curtis,

Thank you for the comments.

Our target in this document is to raise the question of multihoming
in personal and/or small/medium enterprise networks, so for now
we were not looking at the mobile device such as smartphones
connected to both 4g and wifi (for this, the multihoming solution
must be implemented directly on the device). We believe that
SOHO would be interested being multihomed but can't afford the
cost of operating multihoming themselves. This is why we suggest
the MSP which is a way to outsource multihoming complexity.

Now, let's go to the technical part. We didn't want to provide
solution so far but we had in mind the following:

1. traffic is tunnelled between the network and the MSP.

2. addresses assigned to devices in the network belong to
the MSP (or at least are advertised by the MSP in BGP) and
then they never change.

3. the MSP box has one wire (possibly vie wifi or 3/4G) per
ISP to which the network is connected and each NIC connected
to this wire receives addresses dynamically.

Putting these three points together, it means that the gw are
invisible to the devices in the network, that addresses of devices
never change during communications and that traffic always go
through the MSP (even though it is possible to avoid this).

I agree that there is no such thing as the MSP so far, but there
is a bunch of very big service providers that exist today, that are
peering with virtually every significant network and that would
certainly be happy to be the first hop for all the communications.


Thank you,

Damien Saucez

On 01 Oct 2012, at 03:21, Curtis Villamizarcur...@occnc.com  wrote:


In message08880dcf-fec8-4b52-8db4-0300ac1ec...@ericsson.com
Wassim Haddad writes:


Dear all,

We have submitted a problem statement for multihoming in homenet.
Comments appreciated!

Regards,

Wassim H.

Wassim,

You are proposing a solution, not submitting a problem statement.

A problem with your solution is that the most common multihoming is
the mobile device having IP access through both WiFi (via DSL or cable
or hotspot) and 4G mobile.  In this case the MSP middlebox you
propose would have to be inside the mobile device, which is already
both one of the gateways and the end host.

Another problem is the current non-existance of a Multihoming Service
Provider (MSP) somewhere out in the cloud to replace the source
address of packets.

No where in your document does the principle issue with multihoming
get addressed.  The source address used by the host must be chosen
somehow by the host or replaced somewhere.  The function of the MSP
middlebox as described is only to redirect outgoing packets.  If the
source address reflect going through ISP2, and that link goes away,
then the packets can now go out through ISP1 but the problem of using
the wrong source address remains.

If the source address is somehow provided by the MSP, then the traffic
has to be tunnelled from MSP middlebox to MSP as might be implied by
the last paragraph in section 4 where it says In addition, if Gw1 and
Gw2 provide addresses by the mean of DHCPv6 or RA, addresses at the
MSPMB will be configured automatically as well.  The word address
barely appears in the draft except for the prior statement and one in
the intro saying why Shim6 or MPTCP should not be used.  The word
tunnel doesn't appear at all.  The word source (as in source
address) doesn't appear at all.

So you don't seem to be proposing a viable solution or perhaps you had
something to do with tunnelling in mind that you didn't describe at
all clearly.

Curtis



Begin forwarded message:


From: internet-dra...@ietf.orginternet-dra...@ietf.org
Subject: I-D Action: draft-haddad-homenet-multihomed-00.txt
Date: September 25, 2012 10:55:38 AM PDT
To: i-d-annou...@ietf.orgi-d-annou...@ietf.org
Reply-To: internet-dra...@ietf.orginternet-dra...@ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts directories.


Title   : Multihoming in Homenet
Author(s)   : Wassim Haddad
 Damien Saucez
 Joel Halpern
Filename: draft-haddad-homenet-multihomed-00.txt
Pages   : 7
Date: 2012-09-25

Abstract:
  So far, multihoming in Homenet must be supported by the hosts as
  there is no mean to use simultaneously the different Internet Service
  Providers of the Homenet without risking flow disruption.  In this
  memo, we describe the problem statement for multihoming in Homenet.
  We also propose a 

Re: [homenet] Unicast DNS within the Homenet?

[Ray Hunter]

Sure, but the scope of this discussion is name resolution in Homenet, 
where there is always at least 1 router present.

So these two devices could always use unicast to reach a rendezvous point.

What devices do on other ephemeral ad hoc networks is out of scope.

joel jaeggli mailto:joe...@bogus.com
13 September 2012 18:27
On 9/12/12 10:35 PM, Ray Hunter wrote:
Fair counter point to my suggestion. Enterprises don't generally put 
laptops in public viewable DNS.


Isn't your requirement to support highly mobile devices a good reason 
to avoid mDNS wherever possible?
MDNS has a purpose, which is to locate on-link resources. particularly 
if a network is adhoc or ephemeral it seems like the appropriate tool 
for that. two devices forming an adjacency may have no other network.


[mDNS being link local specific, and any extensions/gateways from 
mDNS to unicast DNS will also be local network specific, so your 
favourite coffee shop network may not support them]


regards,
RayH

Mark Andrews mailto:ma...@isc.org
13 September 2012 03:02

Note updating DNS involves both FORWARD and REVERSE entries and the
solutions can be different.

My machines have names. Those names don't change as I move around
the world. Random DHCP servers at coffee shops DO NOT have the
ability to update the DNS entries for those names. They do have the
authority to update the PTR records in in-addr.arpa and ip6.arpa
namespaces.


 


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



Ray Hunter mailto:v6...@globis.net
13 September 2012 07:35
Fair counter point to my suggestion. Enterprises don't generally put 
laptops in public viewable DNS.


Isn't your requirement to support highly mobile devices a good reason 
to avoid mDNS wherever possible?


[mDNS being link local specific, and any extensions/gateways from mDNS 
to unicast DNS will also be local network specific, so your favourite 
coffee shop network may not support them]


regards,
RayH
snip
Mark Andrews mailto:ma...@isc.org
13 September 2012 03:02

Note updating DNS involves both FORWARD and REVERSE entries and the
solutions can be different.

My machines have names. Those names don't change as I move around
the world. Random DHCP servers at coffee shops DO NOT have the
ability to update the DNS entries for those names. They do have the
authority to update the PTR records in in-addr.arpa and ip6.arpa
namespaces.

Machines start off with mDNS to avoid bootstrap problems. They
then have the ability to get a TSIG using TKEY signed with a
administrators TSIG (think Username/Password pair) for the forward
zone. This will be stored in non-volitile storage on the master
nameserver and on the client. Once the client has the TSIG key it
uses that to update its own forward entries.

Machines register PTR records in the reverse zones using TCP as the
authenticator in the reverse zone unless there is a DHCP option
that says to use the DHCP server to relay the PTR record update.

Ted Lemon mailto:mel...@fugue.com
12 September 2012 14:36

Two reasons. First, there's strong opposition to this, and so it will 
never happen, whether it is the right idea or not (I don't think it's 
particularly the right idea, although I'm not vehemently opposed to it 
either). Secondly, it precludes the use of CGA by hosts.


Ray Hunter mailto:v6...@globis.net
12 September 2012 08:41
Ted, respect your DHCP/DNS knowledge, but if we need a DHCP server 
anyway in Homenet, why don't we go for the classic enterprise set up 
that has run for years for IPv4, rather than trying to shoe horn 
locally assigned SLAAC addresses into global DNS?


It's not as though you can buy any piece of domestic networking 
equipment today that does not support DHCPv4, so why not DHCPv6?


So we'd have:
Homenet router - ISP = DHCP-PD to learn prefixes [existing]
in Homenet prefix allocation  distribution [work in progress]
DHCPv6 from the Homenet router to the ISP could be extended to 
communicate any ISP DNS domain settings to the Homenet [gap]

elect/configure a unicast DNS server for Homenet [gap]
run standard unicast DNS [existing]
elect/configure a DHCPv6 server for use within Homenet [gap]
The routers that are acting as clients for DHCP-PD would seem good 
candidates.

run standard DHCPv6 server on local Homenet router[existing]
configure DHCPv6 relay per Homenet router to point to Homenet DHCPv6 
server[existing standard, although autoconfig is a gap for the 
election process]
use DHCPv6 server to update DNS content using RFC 2316 Dynamic DNS 
update on behalf of end clients [existing]
client - Homenet router RFC 3315 DHCPv6 based address configuration, 
and standard unicast DNS [existing]


Then the client only needs to do stuff that is already incorporated in 
any operating system used in business.


Or is this stateless /stateful war still too fresh in the collective

Re: [homenet] Unicast DNS within the Homenet?

[Ray Hunter]

Ted, respect your DHCP/DNS knowledge, but if we need a DHCP server 
anyway in Homenet, why don't we go for the classic enterprise set up 
that has run for years for IPv4, rather than trying to shoe horn locally 
assigned SLAAC addresses into global DNS?


It's not as though you can buy any piece of domestic networking 
equipment today that does not support DHCPv4, so why not DHCPv6?


So we'd have:
Homenet router - ISP = DHCP-PD to learn prefixes [existing]
in Homenet prefix allocation  distribution [work in progress]
DHCPv6 from the Homenet router to the ISP could be extended to 
communicate any ISP DNS domain settings to the Homenet [gap]

elect/configure a unicast DNS server for Homenet [gap]
run standard unicast DNS [existing]
elect/configure a DHCPv6 server for use within Homenet [gap]
The routers that are acting as clients for DHCP-PD would seem good 
candidates.

run standard DHCPv6 server on local Homenet router[existing]
configure DHCPv6 relay per Homenet router to point to Homenet DHCPv6 
server[existing standard, although autoconfig is a gap for the election 
process]
use DHCPv6 server to update DNS content using RFC 2316 Dynamic DNS 
update on behalf of end clients [existing]
client - Homenet router RFC 3315 DHCPv6 based address configuration, 
and standard unicast DNS [existing]


Then the client only needs to do stuff that is already incorporated in 
any operating system used in business.


Or is this stateless /stateful war still too fresh in the collective 
IETF memory?


Ted Lemon wrote:

On Sep 11, 2012, at 11:17 AM, Kerry Lynnker...@ieee.org  wrote:

Can we explore how this auto-population might occur?  It seems that to
glean bindings from mDNS or LLMNR there would have to be at least
(or exactly?) one agent per subnet.  The natural place for the agent to
reside is on the router.  Presumably each agent learns the address of
the DNS server via stateless DHCPv6.  The DNS server would need to
be configured with a TSIG for each agent.  The agent hears multicast
responses to lookups on its local link, then periodically updates the
DNS server.

I assume an alternative would be to auto-configure via stateful DHCPv6.
Would that more or less of a configuration burden than the sketch above?
Would work with existing devices?


There are a couple of options being pursued in the DHC working group; the DHCP 
address registration process would be an obvious mechanism for leveraging DHCP 
to populate the DNS.   The idea here is that you do RA+SLAAC, or RA+CGA, and 
then you contact the DHCP server to tell it what address you allocated and what 
name you want associated with it, and to get any local network configuration 
information you might need.

However, of course this is new technology that isn't even standardized yet.   
I'd like it if homenet recommended implementing this, but I think another way 
of populating the DNS is through mDNS—when a host publishes its name in mDNS, 
it's assumed to be valid as long as no conflicting registration has been made 
locally.   I don't particularly love this method because mDNS doesn't have the 
same duplicate detection features that DHCP does through the DUID, but it 
wouldn't be _worse_ than plain mDNS, and would allow the DNS resolver to query 
a consistent FQDN tree for local names, so that it would work whether you were 
attached to the local wire or not.



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

Re: [homenet] Unicast DNS within the Homenet?

[Ray Hunter]

Fair counter point to my suggestion. Enterprises don't generally put 
laptops in public viewable DNS.


Isn't your requirement to support highly mobile devices a good reason to 
avoid mDNS wherever possible?


[mDNS being link local specific, and any extensions/gateways from mDNS 
to unicast DNS will also be local network specific, so your favourite 
coffee shop network may not support them]


regards,
RayH

Mark Andrews mailto:ma...@isc.org
13 September 2012 03:02

Note updating DNS involves both FORWARD and REVERSE entries and the
solutions can be different.

My machines have names. Those names don't change as I move around
the world. Random DHCP servers at coffee shops DO NOT have the
ability to update the DNS entries for those names. They do have the
authority to update the PTR records in in-addr.arpa and ip6.arpa
namespaces.




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

Re: [homenet] tunnels as way to disambiguate .local

[Ray Hunter]

I disagree. The context of my message is that there should be some 
identifier that can disambiguate the namespace per Homenet. I'm talking 
about using the ULA to generate a HomenetID for use in the namespace. 
See RFC6281.


The HomenetID and DNS subomain (or as you put it 
somethingveryobscure) may be generated by one unique host (e.g. each 
Homenet border router) based on a ULA.  But that does not mean it cannot 
be discovered by all hosts and routers in the Homenet (via some bunch of 
discovery mechanisms such as automatic prefix distribution for 
router-router and DHCPv6 for router - fridge).


The HomenetID will remain constant as long as the ULA of the border 
router remains constant. If it appears to vary (because the border 
router changes) then highly mobile nodes will get some indication that 
they may not be connected to their own Homenet, and ask for user input 
to accept an update. Static nodes would only know their local HomenetID, 
and if it changed they could be set to always accept the update without 
user input. Eventually you would probably end up with a search list 
linked to the number of border routers the end node has ever 
encountered, but end nodes can automatically age out old entries.


We might also want to be able to manually override the auto-generated 
HomenetID to cover the case where border router hardware is replaced by 
the user, but that's no different to MAC address cloning on CPE's in the 
past (where ISPs used the MAC address of the CPE as an identifier in 
management systems).


Sure there's a downside in complexity of the namespace. The potential 
upside of this approach is that the same 
somethingveryobscure.sitelocal. zone file could also be mounted as a 
secondary on somethingveryobscure .ISP DNS root or 
somethingveryobscure .employer's DNS root if the ISP or enterprise 
wished to provide this service for global name resolution. Highly mobile 
nodes would only need two items in their DNS search list, the search 
list can be pretty much auto-generated, and they can use the same name 
resolution technology (DNS) wherever they are located. It also 
completely avoids trying to synch mDNS with DNS, which I think you'll 
agree is likely to be very difficult.



Curtis Villamizar mailto:cur...@occnc.com
4 August 2012 22:06
With all due respect, any suggestion to use the ULA in a domain name
produces either a domain that is unique to one host or a domain that
is every bit as global as sitelocal, depending on whether by stating
ULA prefix you mean the local ULA or the well-known global ULA
prefix.

In rfc4193:

Local IPv6 unicast addresses have the following characteristics:

- Globally unique prefix (with high probability of uniqueness).

- Well-known prefix to allow for easy filtering at site
boundaries.

[...]

If you mean the first (the local ULA prefix), then the domain is
unique to one host. My computer could never find my fridge using the
hostname fridge unless it knew every ULA on the local network and
created an entry in the dns search path. Very long entries in the dns
search path are a very bad thing (tm).

If you means the second (the assigned prefix under which all ULA fall)
then the domain is common to all hosts in the universe that generate a
ULA address. The only difference is it is
host.somethingveryobscure.sitelocal.

Curtis


In message 501965d4.1040...@globis.net



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

Re: [homenet] tunnels as way to disambiguate .local

[Ray Hunter]

Isn't it possible to combine the two ideas of sitelocal. with 
pseudo-domains generated from ULA to give a usable solution?


e.g. fridge.pseudo-ula-domain.sitelocal.

Don't you then avoid the evilness of identifier overloading (my fridge 
versus your fridge) and potential problems with clashing TLD's?
e.g. someone registering a bunch of pseudo-ula-domain. TLD records as 
their company brand for manual administration.


How else are homenet devices going to know not to bother the root 
servers with fridge.pseudo-ula-domain. NS queries given that TLD's are 
now basically a free for all?


Wouldn't it also potentially give a unique anchor point for storing 
DNSSEC zone signing with an implicit sitelocal. trust anchor?


regards,
RayH


Brian E Carpenter wrote:

Synthesise a pseudo-TLD from the ULA prefix.

 Brian





Brian E Carpenter wrote:

On 01/08/2012 05:48, Curtis Villamizar wrote:
...

fridge.sitelocal. is a FQDN with site local scope.


And therefore intrinsically evil, just like 10.0.0.0/8 is intrinsically evil.

IMHO we shouldn't be discussing how to make it work less badly; we should
be discussing how to avoid it entirely.

 Brian


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

Re: [homenet] Name service design principles: a proposal

[Ray Hunter]

 for highly mobile nodes
with flexible tethering, such as iDevices. They should just work in and out
of the home, as you move within range of your Homenet wireless.


Hard problem that crosses not just dns, but applications, the network
stack and cryptography. The app that I love that implements this
functionality fairly well is mosh, and even then it only works
presently on ipv4 and that with public ip addresses.

True. But it's what consumers expect.

5. Integrity: Integrated Security

We should be aware of security issues with a .local style namespace over
whatever transport (your iDevice connecting to my evil .local device posing
as a friendly fileserver because you're walking past my open home network).
So there would need to be some extra device pairing if a .local namespace is
used, or see (5).


Drive by wifi exists independently of the .local convention. It's a
network, not naming
problem.
Maybe we can agree that caching of a .local style namespace that is not 
uniquely globally identifiable is problematic (for highly mobile nodes) 
and needs to be addressed.



6. Independent Local Trust Anchor

Strong desire to avoid a heavyweight trust anchor tied into the public DNS.
That would be another important point for me if starting from scratch.
Perhaps the ability to insert a private trust anchor at some nominal point
on the DNS tree that I can use to authenticate between my own devices, other
than being limited to a trust anchor derived from the DNS root. I'm pretty
sure ISP's won't want to have people phoning their help desks asking about
key rotation problems or with how-to questions about key signing keys in
Homenet.


Having a decent trust anchor to start with with any system would be
good. One of my own issues is that the cert system is so broke that
the most secure certs are the ones you generate yourself, but those
throw an error in your browser by default.

I presume you're more than marginally acquainted with Active Directory.

7. Integrated Low Power Version

Ability for low power devices to sleep for extended periods built in from
the get go (naming gateway? naming proxy responder?)

8. Confidentiality: Name space hiding

Ability to hide a portion of the name space to discourage scanning.




regards,
RayH





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




Ray Hunter mailto:v6...@globis.net
29 June 2012 22:30

There are a number of parallels from Homenet to small and large 
enterprises who declared UDI from the global DNS (and set up their own 
private root servers) for any number of reasons. Similarly for WINS 
and mDNS users.


So maybe a useful approach would be to ask what's wrong with DNS 
today that it can't satisfy all of the requirements mentioned or Why 
did these people declare UDI in the first place? or Why did they 
invent that stuff? and more to the point Can it be fixed?


Some of my answers to those questions would be:

1. Availability: Undesirability of fate sharing

I don't want my media streamer and other devices like a smoke alarm 
becoming locally unavailable because I change provider or the Internet 
link is down for an extended period.


2. Easy roll out and maintenance

I can't see Homenet being able to implement DNSSEC today, so we have 
to be aware of cache poisoning in Homenet and how to address that if 
DNS is the chosen solution.


3. One single namespace for all destinations.Coexistence with global DNS.

Strong desire to integrate into the global DNS naming tree. Single 
name space, single query type, no two way synchronization of separate 
name spaces. I make no statement of preference on whether the 
transport has to be native DNS within the home.


4. Support of Highly Mobile out of the shrinkwrap

Changing environments can be especially problematic for highly mobile 
nodes with flexible tethering, such as iDevices. They should just work 
in and out of the home, as you move within range of your Homenet 
wireless.


5. Integrity: Integrated Security

We should be aware of security issues with a .local style namespace 
over whatever transport (your iDevice connecting to my evil .local 
device posing as a friendly fileserver because you're walking past my 
open home network). So there would need to be some extra device 
pairing if a .local namespace is used, or see (5).


6. Independent Local Trust Anchor

Strong desire to avoid a heavyweight trust anchor tied into the public 
DNS. That would be another important point for me if starting from 
scratch. Perhaps the ability to insert a private trust anchor at some 
nominal point on the DNS tree that I can use to authenticate between 
my own devices, other than being limited to a trust anchor derived 
from the DNS root. I'm pretty sure ISP's won't want to have people 
phoning their help desks asking about key rotation problems or with 
how-to questions about key signing keys in Homenet.


7. Integrated Low Power Version

Ability