[homenet] Thinking about the implementer - my comments at mic about .home and RFC 7788

[Dan York]

Just relaying to the list the comments I made at the mic in the WG session on 
Monday...

I did not agree with any of the four choices offered by the chairs to the WG 
for the resolution of the RFC 7788 / .home issue.

I've spent a good bit time over the past four years helping people try to 
implement standards that we create for technologies such as IPv6, DNSSEC, TLS, 
etc.  Developers often attempt to use the RFCs and many wind up finding it too 
confusing of an experience. A few observations:

- Some developers don't pay attention to (or don't see) the "errata" that 
exists on some of the RFCs. (There was a comment in the room on Monday that 
some views of the RFCs don't make it easy to find the errata - I've not 
explored that myself to confirm.) [1]

- Some developers don't understand how our systems work with regard to 
"updates".  They don't understand that an RFC may be updated by another RFC and 
that update may fundamentally alter the original RFC.

They are generally told "you need to implement RFC <> - go do it!" and are 
left to figure that out.

In talking to a couple of developers over the years, they just go to their 
favorite search engine, enter the RFC number and pretty much take the first 
link they find (which may or may not be one of our primary repositories).

I think the easier we can make it for developers to figure out how to implement 
our standards, the better the chance for more deployment.  If we want HOMENET 
to be widely used, we need to make the standards as easy to understand and 
implement.

To me that means a couple of things with regard to RFC 7788 and the .home issue:

1. I would NOT publish any changes we want to make as "errata".

2. I would NOT publish a new RFC that "updates" RFC 7788.

3. I would NOT publish a new RFC that is filled with "internal" analysis of how 
the process broke down AND THEN also updates RFC 7788.  (Someone seeking to 
implement the standard is not going to want to wade through the analysis.)

I think the cleanest, simplest thing we can do *for the implementers* is to 
publish a new RFC that *obsoletes* RFC 7788.  We can then promote the new RFC 
as the definitive standard for HNCP.  RFC 7788 can get a big "Obsolete" warning 
in the places we publish it - and documentation and other new RFCs can 
reference the new RFC.

Just my 2 cents,
Dan

[1] I also know that RFCs are sometimes copied to other locations on the 
Internet where things such as errata and update links are sometimes lost.  I 
realize that's not something we can really address - and we can only hope 
developers seek out the "official" source - but that is also a reality.

--
Dan York
Senior Content Strategist, Internet Society
y...@isoc.org   +1-802-735-1624
Jabber: y...@jabber.isoc.org
Skype: danyork   http://twitter.com/danyork

http://www.internetsociety.org/




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

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

[Andrew Sullivan]

Hi,

On Wed, Jul 20, 2016 at 02:10:05PM +0200, Ray Bellis wrote:
> 
> On 20/07/2016 13:33, Ray Bellis wrote:
> 
> > My expectation is that in a Homenet multi-subnet environment I will be
> > able to just use http://./ and just have it work regardless
> > of which particular subnet that device is on [*].

Note that only one of those expectations is actually given you by RFC
7368 -- that it will just work no matter which subnet you're on.  The
. pattern (assuming TBD is a single label) is not.

> There's a further corollary to this:  since we can't mandate host
> changes, the resolution of that name MUST be unicast DNS to an *on-net*
> resolver.

I think this is probably entailed, but RFC 7368 doesn't say that
either.  It just says that it probably needs to be (or needs to work
somehow with DNS).

> Having different resolvers for different parts of the namespace is a bad
> idea [*]

Except, of course, that's precisely what we have with Bonjour: DNS for
everything except names ending in local.  That label functions as a
protocol switch to tell your combined resolver which names to resolve
by mDNS and which ones to resolve by DNS.

> [ Current host stacks don't have support for saying "if the suffix is
> ".TBD", go here, otherwise go there.  If you have one resolver for
> ".TDB" and another for everything else and then just send all queries to
> both, you still need host changes to cope with how you'll get a valid
> answer from one but not the other ]

Not necessarily.  For instance, you could use Bonjour and the hybrid
proxy approach and do it that way.  It's not clear to me from RFC 7368
whether we're allowed to assume mDNS is available on any host, but
given the zeroconf pattern and the stated desirability of it, probably
we are.

Best regards,

A

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

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

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

[Juliusz Chroboczek]

> Current host stacks don't have support for saying "if the suffix is
> ".TBD", go here, otherwise go there.

Right, and I missed this point in my strawman.  I guess I've been spoiled
by dnsmasq.

-- Juliusz

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

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

[David Lamparter]

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

I do see some trouble in use-cases where more than one actual router
(actual = not counting extra link-local addresses on the same router) is
present on a link, advertising the same prefix to hosts.  (This is
reasonably likely in homenet scenarios, maybe less in enterprise.)

If the host only tracks a maximum of one RA source LL for a
prefix/address, but the router with that LL happens to not be the one
actually used (e.g. preference, router gone, more specific route from
RIO, whatever else) then the functionality is lost.  It's particularly
bad if the one RA source LL is the one prefix was first seen from (and
then, worst-case, never updated).

(The neccessary precondition / assumption being broken there is that the
test "was prefix X announced by router Y" doesn't report false
negatives.  I haven't applied brain to false positives yet.)


-David

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

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

[avri doria]

On 19-Jul-16 18:10, Ted Lemon wrote:
> Please read draft-lemon-sutldr-ps, and participate in the discussion
> about this on the dnsop mailing list.   Discussions about the RFC6761
> problem are off-topic for the homenet mailing list.   We are customers
> of the existing IETF consensus process as documented in RFC 6761.   We
> get into enough ratholes on the homenet mailing list; please don't get
> us into this rathole as well.   

I have done my reading.  Not only of your draft, the discussion in DNSOP
and the other drafts. Do not know why you presumed i hadn't.  Why, I
have even read RFC6761, several times.

I am also happy to avoid rat holes, but as far as I understand the case,
you did not follow the requirements of RFC6761 and thus this unassigned
usage does not have the imprimatur even of RFC6761, for whatever that
ends up being worth.  It was a decision made by this WG for this group's
reasons.  And it was missed in the review cycle.  Unfortunately I find I
only ended up working on this issue on 23 October, just as IET was
ending its last call.  Though I might have missed it as well.

I would also like to point out that the studies done for ICANN are by no
means the end of the story and do not represent a consensus decision of
ICANN at this point.  While there may be a 'restraining order' from the
ICANN Board on assigning the names at this point, that is not a
permanent consensus decision and is a situation that people in ICANN are
still actively working on.  To allocate a name that is under discussion
and contention and had been applied for in 2012,  at this point seems to
me to constitute an infringement of the policy prerogative given to
ICANN by RFC2860.  And while the recent 2015 study may have recommended
that ICANN ask IETF to reserve then name, an incredibly bad idea when
ICANN has its own policy development methods for reserving names, the
ICANN Board has not to my knowledge made any such formal request.

While IETF can certainly assign a name as a protocol parameter according
to RFC6761 ( despite any dispute that may or may not exist on the
validity of that process ) that does not mean they have the ability to
chose any name they wish, only that they may assign a name.  I would
recommend in the spirit of RFC2860 that you chose a name that is not the
point of a disagreement and that had not been applied for in 2012.  I
assume there is no technical reason why .home and only .home must be
used for protocol reasons alone.  As a protocol parameter, I would
assume any relationship between a string and dictionary word was just an
unhappy coincidence, and one to avoid.

If you want to hardcode a name into your protocol, I suggest you pick a
neologism like .homenet  or even .hmnt it you want something short and
pithy, and avoid the rat hole that is .home.

cheers,
avri



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

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

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

[David Lamparter]

On Wed, Jul 20, 2016 at 03:13:05PM +0200, Lorenzo Colitti wrote:
> On Wed, Jul 20, 2016 at 2:54 PM, David Lamparter  wrote:
> 
> > - it's a bit unclear how an address/prefix's "source" next-hop is kept
> >   in association.  The simplistic approach of adding a "PA source ipv6
> >   address" for each of a host's configured addresses falls flat when
> >   more than 1 router advertises the same prefix, so I implemented it as
> >   a list -- however, my hack never removes entries off that.  It should
> >   possibly have a copy of the PA's valid time?
> >
> 
> The way I thought of doing this would be to alternatively/additionally keep
> a pointer from the default router that announced a given prefix (which does
> have the link-local address of the router) to each address that was
> configured from that prefix.

That turns nontrivial as soon as you have 4191 RIOs, especially if the
router is trying to do walled gardens by sending its RAs with lifetime =
0 (as suggested in section 4.2.2 of pa-multihoming).

> That way, when an address goes away you can scan the FIB and find
> another router to associate with that prefix.

[I assume "address goes away" meant "router goes away"]

> As for lifetimes expiring, you would need to have somewhere to keep dummy
> zero-lifetime default routes. It might be possible to do this in the FIB
> itself by adding a special entry that doesn't ever match anything, or has
> an infinite metric, or a different type...

That sounds quite a bit more complicated than address-centric
handling...  we're 1:N for router['s LL address] to routes and also 1:N
for router['s LL address] to prefixes, and then 1:N for prefix to
derived addresses.

I'd rather copy the prefix lifetime (either valid or preferred -
probably former?) onto the same list entry where a configured address's
RA source LL is also stored; that replicates only the last 1:N step...
(So, for each address, in its list of RA sources that the prefix was
seen from, there will be a potentially-distinct lifetime.)


-David

P.S.: Does anyone know the details of how Windows implements this?

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

Re: [homenet] Naming: a strawman counter-proposal

[Ted Lemon]

This proposal doesn't satisfy the problem statement.

(which nobody wrote. :)

I don't want to tube on writing a formal requirements doc before we finish
doing a naming architecture, but I think now that I've taken a stab at
this, we should think about our reactions to and see if we can scope the
problem we are trying to solve in a bit more detail than just "naming and
service discovery on homenets."

On Wed, Jul 20, 2016 at 11:27 AM, Juliusz Chroboczek <
j...@pps.univ-paris-diderot.fr> wrote:

> Not proposing this seriously, just attempting to explore the design space.
> Some of the ideas are due to Toke.
>
> Zones and authoritative nameservers are announced over HNCP together with
> their set of addresses, which SHOULD include a LUA and MUST include at
> least one IPv6 address.  There are two bits associated with each
> authoritative nameserver:
>
>   - default: set to 1 if the zone is suitable for name registration without
> explicit user configuration;
>   - public: set to 1 if the zone is visible from the public internet.
>
> When a router joins the homenet, it MAY announce itself as the new
> authoritative nameserver for a zone.  It SHOULD do so if there is no
> default public or private zone.
>
> If there are two default private zones or two default public zones, we
> call an election, Highlander-style.  If there are two authoritative
> nameservers for the same zone, we call an election.
>
> There are no secondaries.  If there are secondaries, their configuration
> is outside the scope of this mail.
>
> Stateful DHCP servers SHOULD register their clients with the authoritative
> nameserver for the default private zone using your favourite unicast
> mechanism.  Clients MAY register themselves with any zone currently
> announced (they learn the server addresses through HNCP snooping or a from
> new ND option, I don't care).
>
> mDNS proxying into the default private zone is allowed.  Or recommended,
> I'm not sure, only implementation experience will tell.
>
> Why exactly am I speaking nonsense?
>
> -- Juliusz
>
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Brian E Carpenter]

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

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

Brian

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

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

[Brian E Carpenter]

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

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

Brian

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

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

[David Lamparter]

As mentioned on mic during rtgwg, I think the idea of affecting host
source address selection through 6724 rule 5.5 is potentially very
useful and IMHO should be explored.

Hence, I hacked it up for the Linux (4.5.0) kernel; patches are attached
to this mail.  I've been able to gleam a little more detail on the idea:

- it's a bit unclear how an address/prefix's "source" next-hop is kept
  in association.  The simplistic approach of adding a "PA source ipv6
  address" for each of a host's configured addresses falls flat when
  more than 1 router advertises the same prefix, so I implemented it as
  a list -- however, my hack never removes entries off that.  It should
  possibly have a copy of the PA's valid time?

  (Read as: the "Discussion" note in 6724 is right on the mark - the
  details are not quite specified.)

- in that avenue, I don't think it's possible to store the information
  in a route-centric way, because RA lifetimes tend to be shorter.
  If a router goes away and comes back, it seems to me that the prefix's
  associated origin/nexthop should still be there.

- rule 5.5 makes RA preference carry into source address selection.  I
  think this is described in the draft, I just failed to grasp that from
  the presentation.  Very useful for getting source selection right in
  the face of unequal performance uplinks.

- if you want to manage this in an userspace process on Linux, you can
  simply update the route's preferred source attribute.

The attached patchset also has the following caveats that result from me
just doing a quick hack:
- there is no debugging/user visibility of the value
- as mentioned above, tracked source addresses never go away unless the
  entire address dies.  It caps at 4 sources (so you can't exhaust
  kernel memory by spoofing...)
- I should probably pass Linux's "dst" instead of "rt6_info"
- I didn't check for locking/concurrentness violations
- there's a const warning which I ignored.

Either way if anyone wants to tinker with it, here it is.
No warranties, YMMV.  You touch it, it becomes your responsibility ;)

Cheers,


-David

On Wed, Jul 06, 2016 at 04:33:18PM +, Fred Baker (fred) wrote:
> At IETF 94, this working group advised the routing ADs and Routing Working 
> Group that PA multihoming would not work without a source/destination routing 
> solution. This draft was developed in response. Routing Working Group 
> requests v6ops review.
> 
> > Begin forwarded message:
> > 
> > From: 
> > Subject: New Version Notification for 
> > draft-bowbakova-rtgwg-enterprise-pa-multihoming-00.txt
> > Date: July 5, 2016 at 5:58:25 PM PDT
> > To: Chris Bowers , Jen Linkova , 
> > "Fred Baker" , "J. Linkova" 
> > 
> > 
> > A new version of I-D, draft-bowbakova-rtgwg-enterprise-pa-multihoming-00.txt
> > has been successfully submitted by Fred Baker and posted to the
> > IETF repository.
> > 
> > Name:   draft-bowbakova-rtgwg-enterprise-pa-multihoming
> > Revision:   00
> > Title:  Enterprise Multihoming using Provider-Assigned 
> > Addresses without Network Prefix Translation: Requirements and Solution
> > Document date:  2016-07-05
> > Group:  Individual Submission
> > Pages:  44
> > URL:
> > https://www.ietf.org/internet-drafts/draft-bowbakova-rtgwg-enterprise-pa-multihoming-00.txt
> > Status: 
> > https://datatracker.ietf.org/doc/draft-bowbakova-rtgwg-enterprise-pa-multihoming/
> > Htmlized:   
> > https://tools.ietf.org/html/draft-bowbakova-rtgwg-enterprise-pa-multihoming-00
> > 
> > 
> > Abstract:
> >  Connecting an enterprise site to multiple ISPs using provider-
> >  assigned addresses is difficult without the use of some form of
> >  Network Address Translation (NAT).  Much has been written on this
> >  topic over the last 10 to 15 years, but it still remains a problem
> >  without a clearly defined or widely implemented solution.  Any
> >  multihoming solution without NAT requires hosts at the site to have
> >  addresses from each ISP and to select the egress ISP by selecting a
> >  source address for outgoing packets.  It also requires routers at the
> >  site to take into account those source addresses when forwarding
> >  packets out towards the ISPs.
> > 
> >  This document attempts to define a complete solution to this problem.
> >  It covers the behavior of routers to forward traffic taking into
> >  account source address, and it covers the behavior of host to select
> >  appropriate source addresses.  It also covers any possible role that
> >  routers might play in providing information to hosts to help them
> >  select appropriate source addresses.  In the process of exploring
> >  potential solutions, this documents also makes explicit requirements
> >  for how the solution would be expected to behave from the perspective
> >  of an enterprise site network administrator .
> > 
> 

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

[Ray Bellis]

On 20/07/2016 13:33, Ray Bellis wrote:

> My expectation is that in a Homenet multi-subnet environment I will be
> able to just use http://./ and just have it work regardless
> of which particular subnet that device is on [*].



There's a further corollary to this:  since we can't mandate host
changes, the resolution of that name MUST be unicast DNS to an *on-net*
resolver.

Having different resolvers for different parts of the namespace is a bad
idea [*] so furthermore that resolver must also be capable of handling
queries received for the global namespace (whether by forwarding to an
off-net resolver, or performing full iterative resolution itself).

Ray

[ Current host stacks don't have support for saying "if the suffix is
".TBD", go here, otherwise go there.  If you have one resolver for
".TDB" and another for everything else and then just send all queries to
both, you still need host changes to cope with how you'll get a valid
answer from one but not the other ]

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

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

[Ray Bellis]

On 20/07/2016 12:01, Ralph Droms wrote:

> Without that definition, I don't think I know where and by whom the
> label will actually be used.  Will it turn out to be like .local,
> which, as far as I know, is rarely used anywhere and only ever by a
> certain class of expert user.



I have three devices in my home that have web interfaces that are
accessible as http://.local/ because they support Bonjour.

That URL is visible in the browser address bar, and not hidden away in
some device-specific control panel (e.g. the Printer chooser).  One of
those devices is a printer, and is therefore _also_ accessible like
that, hiding the '.local', but the other two are primarily accessed via
a browser.

Since those URLs must also be bookmarkable and because devices might
move around the network, any solution that mandates any subnet-specific
naming scheme would be unacceptable.

My expectation is that in a Homenet multi-subnet environment I will be
able to just use http://./ and just have it work regardless
of which particular subnet that device is on [*].

It's also important to me that I be able to type those addresses in, and
for me that rules out the Unicode house symbol.



I've previously argued that '.home' is fine for our purposes - I'm
coming around to the argument that it's better to start with a
greenfield "TBD" than to risk any conflict.

Ray

[*] notwithstanding name-collision issues...

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

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

[Ted Lemon]

The name should be short, easily recognized, and make some kind of sense.
It is important that the name look reasonable because we want the natural
human pattern matching ability that nearly all users can be expected to
have to notice when someone uses a name that is not quite correct, and to
not reject the name because it looks weird.

Honestly, discussions like this make me feel genuine despair for the IETF.
Why do we keep having this silly argument?  I was up until two in the
morning last night because I couldn't let go of the sorrow and frustration
that I feel about being forced to have this discussion again when we are
already doing with to address this problem in a different working group,
and we already had the same discussion over .onion.

Why do we need to talk this through again?

On Jul 20, 2016 12:42, "Ralph Droms"  wrote:

>
> On Jul 20, 2016, at 12:24 PM 7/20/16, Andrew Sullivan <
> a...@anvilwalrusden.com> wrote:
>
> On Wed, Jul 20, 2016 at 06:05:54AM -0400, Brian Haberman wrote:
>
> If the above holds, I would suggest (only partly in jest) a TLD that
> contains a certain unicode value that can be visually displayed by an OS...
>
> http://apps.timwhitlock.info/unicode/inspect/hex/1F3E0
>
>
> This is the second time this has been suggested, actually, and the
> only problem with it is that anything not somehow a letter or digit
> isn't permitted under IDNA2008, which means that no emoji are allowed.
> (There are actually good reasons for this -- it turns out to be hard
> to read emoji out loud, for instance.)
>
>
> Perhaps we could use the punycode, xn--um8h?  That choice would be
> wonderfully ironic in that the only people who ever use the label will get
> the joke...
>
>
> Best regards,
>
> A
>
> --
> Andrew Sullivan
> a...@anvilwalrusden.com
>
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
>
>
>
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
>
>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[joel jaeggli]

On 7/20/16 12:24 PM, Andrew Sullivan wrote:
> On Wed, Jul 20, 2016 at 06:05:54AM -0400, Brian Haberman wrote:
>> If the above holds, I would suggest (only partly in jest) a TLD that
>> contains a certain unicode value that can be visually displayed by an OS...
>>
>> http://apps.timwhitlock.info/unicode/inspect/hex/1F3E0
> 
> This is the second time this has been suggested, actually, and the
> only problem with it is that anything not somehow a letter or digit
> isn't permitted under IDNA2008, which means that no emoji are allowed.
> (There are actually good reasons for this -- it turns out to be hard
> to read emoji out loud, for instance.)

家 become homograph attacks are grand

> Best regards,
> 
> A
> 




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

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

[Andrew Sullivan]

On Wed, Jul 20, 2016 at 06:05:54AM -0400, Brian Haberman wrote:
> If the above holds, I would suggest (only partly in jest) a TLD that
> contains a certain unicode value that can be visually displayed by an OS...
> 
> http://apps.timwhitlock.info/unicode/inspect/hex/1F3E0

This is the second time this has been suggested, actually, and the
only problem with it is that anything not somehow a letter or digit
isn't permitted under IDNA2008, which means that no emoji are allowed.
(There are actually good reasons for this -- it turns out to be hard
to read emoji out loud, for instance.)

Best regards,

A

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

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

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

[Brian Haberman]

On 7/20/16 6:01 AM, Ralph Droms wrote:
> 
>> On Jul 20, 2016, at 11:50 AM 7/20/16, Juliusz Chroboczek
>>  wrote:
>> 
 We want something short and memorable.  ".co.uk" is short and
 memorable. ".univ-paris-diderot.fr" is not.
>> 
>>> Why?  This is, I suspect, part of the issue: it seems that we
>>> have some assumptions about the use of these names, and I'm not
>>> entirely sure what they are.  It is not obvious to me that "short
>>> and memorable" is a requirement that falls out of section 3.7 of
>>> RFC 7368.
>> 
>> I suggest we put this question to the WG.  Perhaps the chairs would
>> be willing to ask whether the WG would prefer a name that is short
>> and memorable, or one that is long and impossible to remember?
> 
> I think there are some important questions to answer first:
> 
> What is the meaning of .home and, precisely, how will names that end
> in .home be resolved?
> 
> Where and by whom will this label actually be used?  What is the
> research to back up the answer?
> 
> Although many people have given me a answer to the first question,
> and the answers often include phrases like "it just means..." or
> "everybody agrees that..." or "it's obvious...", I don't think I've
> seen a citable definition for the intention and semantics of .home;
> pointers welcome.
> 
> Without that definition, I don't think I know where and by whom the
> label will actually be used.  Will it turn out to be like .local,
> which, as far as I know, is rarely used anywhere and only ever by a
> certain class of expert user.
> 

If the above holds, I would suggest (only partly in jest) a TLD that
contains a certain unicode value that can be visually displayed by an OS...

http://apps.timwhitlock.info/unicode/inspect/hex/1F3E0

Regards,
Brian



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

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

[Suzanne Woolf]

> On Jul 20, 2016, at 5:50 AM, Juliusz Chroboczek 
>  wrote:
> 
>>> We want something short and memorable.  ".co.uk" is short and memorable.
>>> ".univ-paris-diderot.fr" is not.
> 
>> Why?  This is, I suspect, part of the issue: it seems that we have
>> some assumptions about the use of these names, and I'm not entirely
>> sure what they are.  It is not obvious to me that "short and
>> memorable" is a requirement that falls out of section 3.7 of RFC 7368.
> 
> I suggest we put this question to the WG.  Perhaps the chairs would be
> willing to ask whether the WG would prefer a name that is short and
> memorable, or one that is long and impossible to remember?

Plenty of useful names— domain names and otherwise— are neither short nor 
memorable. Some are one but not the other. And while “short” is an objectively 
quantifiable property, “memorable” is quite a lot fuzzier. 

I admit I’m still not sure who’s going to see these names, so I don’t know for 
whom they’re intended to be memorable.

Which leads me to wonder why “short, memorable, already known to be polluted by 
other uses, and already the subject of an allocation process in another 
organization” is preferable to “short, memorable, highly likely to be 
conflict-free, and uncontroversial”?

I still hope for answers to the questions several of us have now asked 
repeatedly about how these names will be used. So far, I’ve heard repeatedly 
why “home” is believed to be an acceptable string to serve this purpose. What 
continues to confuse me is why it’s apparently believed to be the one and only 
acceptable string, or even the most preferred one.



Suzanne


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

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

[Ralph Droms]

> On Jul 20, 2016, at 11:50 AM 7/20/16, Juliusz Chroboczek 
>  wrote:
> 
>>> We want something short and memorable.  ".co.uk" is short and memorable.
>>> ".univ-paris-diderot.fr" is not.
> 
>> Why?  This is, I suspect, part of the issue: it seems that we have
>> some assumptions about the use of these names, and I'm not entirely
>> sure what they are.  It is not obvious to me that "short and
>> memorable" is a requirement that falls out of section 3.7 of RFC 7368.
> 
> I suggest we put this question to the WG.  Perhaps the chairs would be
> willing to ask whether the WG would prefer a name that is short and
> memorable, or one that is long and impossible to remember?

I think there are some important questions to answer first:

What is the meaning of .home and, precisely, how will names that end in .home 
be resolved?

Where and by whom will this label actually be used?  What is the research to 
back up the answer?

Although many people have given me a answer to the first question, and the 
answers often include phrases like "it just means..." or "everybody agrees 
that..." or "it's obvious...", I don't think I've seen a citable definition for 
the intention and semantics of .home; pointers welcome.

Without that definition, I don't think I know where and by whom the label will 
actually be used.  Will it turn out to be like .local, which, as far as I know, 
is rarely used anywhere and only ever by a certain class of expert user.

- Ralph

> 
>> But worse, "home" is actually only memorable for people who know what
>> that word is in English,
> 
> I seem to always hear this argument from native speakers of English.
> I have spent much of the last 20 years working with native speakers of
> French and Maghribi Arabic, many of whom have very little English, and we
> have never had any issue with remembering short English words without
> complex consonant clusters ("for" and even "while" are fine, but "length"
> tends to cause problems).  My sample is certainly biased, but these are
> first year students at a non-elite university (no tuition fees), so they
> are probably representative of the public we're aiming for.
> 
>> and it's only even useful to people who use Latin characters.
> 
> I could be wrong, but I do not believe there exists any country in the
> world where literate people are not familiar with the Latin alphabet.
> 
> -- Juliusz
> 
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Juliusz Chroboczek]

>> We want something short and memorable.  ".co.uk" is short and memorable.
>> ".univ-paris-diderot.fr" is not.

> Why?  This is, I suspect, part of the issue: it seems that we have
> some assumptions about the use of these names, and I'm not entirely
> sure what they are.  It is not obvious to me that "short and
> memorable" is a requirement that falls out of section 3.7 of RFC 7368.

I suggest we put this question to the WG.  Perhaps the chairs would be
willing to ask whether the WG would prefer a name that is short and
memorable, or one that is long and impossible to remember?

> But worse, "home" is actually only memorable for people who know what
> that word is in English,

I seem to always hear this argument from native speakers of English.
I have spent much of the last 20 years working with native speakers of
French and Maghribi Arabic, many of whom have very little English, and we
have never had any issue with remembering short English words without
complex consonant clusters ("for" and even "while" are fine, but "length"
tends to cause problems).  My sample is certainly biased, but these are
first year students at a non-elite university (no tuition fees), so they
are probably representative of the public we're aiming for.

> and it's only even useful to people who use Latin characters.

I could be wrong, but I do not believe there exists any country in the
world where literate people are not familiar with the Latin alphabet.

-- Juliusz

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

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

[Wouter Cloetens]

On 20/07/16 11:10, Andrew Sullivan wrote:

On Wed, Jul 20, 2016 at 12:13:12AM +0200, Juliusz Chroboczek wrote:

- why do you need a word from natural language?

We want something short and memorable.  ".home" is short and memorable.
".in-addr.arpa" is not.

"Something short and memorable" is again a requirement here that isn't
obviously imposed by RFC 7368.  But worse, "home" is actually only
memorable for people who know what that word is in English, and it's
only even useful to people who use Latin characters.
Speaking as a residential gateway (stack) vendor who has deployed close 
to 20 million units in (at my last count) 15 countries across Europe, 
the Middle East and Africa, none of them English speaking, primarily in 
France which is very protective of its language, I would say that that 
is a non-issue. The DNS lingua franca started with Latin for .edu, .com, 
.mil, .org, and moved to English with the likes of .net, .biz and most 
gTLD's. There is a global acceptance that English and the Latin 
character set are used for some things on the Internet, and everyone can 
input left-to-right, Latin character strings on their keyboards. Nobody 
is calling for translations of "http" or "www", to my knowledge.


"Short and memorably" seems like an obvious goal to me. .home fits this, 
and is a well known word among non-English speakers. Even 
extraterrestrials point at the night sky and request to "phone home."


A notable exception is Deutsche Telekom whose gateways use ".lan". Which 
is an English acronym.


bfn, Wouter

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

[homenet] Naming: a strawman counter-proposal

[Juliusz Chroboczek]

Not proposing this seriously, just attempting to explore the design space.
Some of the ideas are due to Toke.

Zones and authoritative nameservers are announced over HNCP together with
their set of addresses, which SHOULD include a LUA and MUST include at
least one IPv6 address.  There are two bits associated with each
authoritative nameserver:

  - default: set to 1 if the zone is suitable for name registration without
explicit user configuration;
  - public: set to 1 if the zone is visible from the public internet.

When a router joins the homenet, it MAY announce itself as the new
authoritative nameserver for a zone.  It SHOULD do so if there is no
default public or private zone.

If there are two default private zones or two default public zones, we
call an election, Highlander-style.  If there are two authoritative
nameservers for the same zone, we call an election.

There are no secondaries.  If there are secondaries, their configuration
is outside the scope of this mail.

Stateful DHCP servers SHOULD register their clients with the authoritative
nameserver for the default private zone using your favourite unicast
mechanism.  Clients MAY register themselves with any zone currently
announced (they learn the server addresses through HNCP snooping or a from
new ND option, I don't care).

mDNS proxying into the default private zone is allowed.  Or recommended,
I'm not sure, only implementation experience will tell.

Why exactly am I speaking nonsense?

-- Juliusz

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

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

[Andrew Sullivan]

On Wed, Jul 20, 2016 at 12:13:12AM +0200, Juliusz Chroboczek wrote:
> > - why do you need a TLD? Why won't a SLD work?
> 
> We want something short and memorable.  ".co.uk" is short and memorable.
> ".univ-paris-diderot.fr" is not.

Why?  This is, I suspect, part of the issue: it seems that we have
some assumptions about the use of these names, and I'm not entirely
sure what they are.  It is not obvious to me that "short and
memorable" is a requirement that falls out of section 3.7 of RFC 7368. 
 
> > - why do you need a word from natural language?
> 
> We want something short and memorable.  ".home" is short and memorable.
> ".in-addr.arpa" is not.

"Something short and memorable" is again a requirement here that isn't
obviously imposed by RFC 7368.  But worse, "home" is actually only
memorable for people who know what that word is in English, and it's
only even useful to people who use Latin characters.  It's not like
internationalization considerations in naming are unknown (and it
would appear that if there is a requirement for natural language
strings then we haven't attended to RFC 2277 section 6).  Since the
point of this is to be intuitive for users who aren't professional
administrators, I guess I assumed that it also has to be intuitive for
such users who happen not to speak and read English.  I'm prepared to
admit my assumption may be wrong, but if so I'd like the WG to think
about that first.

> flexibility is not needed or not desirable.  In the particular case of the
> choice of the top-level domain, there is agreement in this WG that having
> a standardised default is more robust, more predictable, and easier to
> understand than using a distributed consensus algorithm.

It appears to me that an interpretation equally consistent with the
results of the WG is that the WG proceeded with a simplifying
assumption and more or less ignored the details implicit in this
issue, partly because the WG had already decided mostly to kick the
issue of naming down the road a little.

I appreciate that it's annoying to discover that there's a problem
quite this late, and it's super annoying that we have to cope with it
quickly.  And I take my full share of the blame: I missed this, and
should not have.  But cope with it we must, because the use of
home. or any other name without having answered the questions in
section 5 of RFC 6761, and without registering a well-known domain
name in the DNS, is bad for the network and a threat to the very users
we're supposed to be serving with this effort.

Best regards,

A

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

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

Re: [homenet] My comment about Ted's naming draft

[Ted Lemon]

On Jul 20, 2016 00:13, "Toke Høiland-Jørgensen"  wrote:
> > These are some fairly ambitious requirements, and I believe that they
> > deserve discussion separately from the naming issue.  More precisely:
> >
> > (1) Are wo to go to the effort of specifying and deploying a new ND
option?

Why is this hard?

> As I read this, it is mostly an optimisation and could be left out in
> favour of simply timing out. Presumably the case it is solving (homenet
> configuration lost) is so uncommon that having a simple timeout is
> better than a new option that is probably not going to be very well
> tested in any case.

Maybe so. We should think about this. In any case, remember that the
architecture document is the list of what are trying to accomplish. Seeing
high goals is okay. If we realized that this is an optimization with little
value, we don't have to do it.

> > (2) Defining a management API goes against the Homenet tradition, which
> > is to negotiate things over HNCP rather than defining new APIs.
>
> I agree that the "Restful API" sticks out a bit in the document.

Restful is probably overspecifying.

> Could the
> document not just specify that there must be some way to configure it
> appropriately, and leave the details to the implementations?

This would represent failure. Leaving it to the implementation means no
interop, which means vendor lock in.

> As I read this, a resolver on each link is required to filter out
> spurious DNS updates (last sentence in section 4.1). If some other
> mechanism to prevent this is substituted, presumably the requirement to
> have a resolver on every link could be dropped?

Send text proposing this new alternative. However, it doesn't need to be a
full blown resolver. It could just proxy. But there does need to be at
least one resolver in the homenet.

> Another thing that stuck out to me was the suggestion (in section 6.1)
> to stick a captive portal in the user's face if there's a configuration
> problem (or does "triggering captive portal detection" instead refer to
> hijacking just the DNS names that, say, Android uses to detect the
> presence of a captive portal?). Not sure I agree that's a good idea -
> apart from captive portals being annoying as hell, this is again
> specifying a UI element in detail; should the spec really do that?

We need a way to contact the user. This is an easy way. I am open to other
ideas.

> Finally, the mechanism outlined in section 4.8 to use the homenet
> services outside the homenet seems somewhat brittle to me. It involves
> both caching logic and key management. I'm not sure to what extent this
> is considered a killer feature. Would it be unreasonable to tell users
> to simply add services they want to access from off-network to the
> public zone?

No. However, this is certainly a nice to have, not a must.
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] About ULAs in Ted's draft

[Juliusz Chroboczek]

> ps - i've read the draft and think it's ready for adoption.

I most humbly disagree.  Let's please leave some time for people to think
it over and possibly come with counter-proposals.

-- Juliusz

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