Re: [homenet] a modest proposal

[Mikael Abrahamsson]

On Wed, 1 Aug 2012, Curtis Villamizar wrote:


Same answer as one given on that thread.  If a device can support
IPv4, then use NAT4.  If a device can only support IPv6, then the
DNS64 belongs on the IPv6-only device.  To that device all host return


Am I interpreting you correctly in that you're saying that an IPv6 only 
device should have a built in resolver that does DNS64 in case of v6 only 
connectivity?


I can see that this would work, but is that a generally accepted solution? 
On Android, this would mean that dnsmasq would need to gain DNS64 
functionality (and also needs to be able to detect the NAT64 prefix 
somehow).


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

Re: [homenet] tunnels as way to disambiguate .local

[Michael Richardson]

> "Evan" == Evan Hunt  writes:
>> Do we want applications caching mDNS replies into configuration
>> files?  I think not, and I think the DNS people will shout loudly
>> about that.

Evan> Hm... I'm a DNS people, but I'm not sure I object to this.
Evan> You'd want some mechanism for clearing old records out after
Evan> the devices had been gone from the network for a long-enough
Evan> time, but that's not intrinsically hard.

so, after your ISP renumberers you (not a flash renumber), or if you
change routers (get a new ULA), or change ISPs, you have to discover
your printer again?

Evan> I'm of the opinion that "remote access from offsite" should be
Evan> a service you can configure your printer to provide, but which
Evan> is not the default.

Uhm, so let's seperate discovery, naming, and reachability from
authorization.  (being able to reach it doesn't mean you can print...)

Evan> In my ideal world (please indulge me in a moment of
Evan> handwaving), you plug in your printer, and tell it what its
Evan> name is (or let it pick its own default such as
Evan> "LaserPrinter-3"); it announces itself to the local network as
Evan> providing local printing, and its name is placed in the
Evan> .sitelocal domain.

okay, so far.

Evan> *If* you check the box for "let the outside world print to me"
Evan> -- which you and I might want to do but most people wouldn't

I agree that this is a box.  I'd like to see some more authentication
and authorization things happen, but that's a detail for CUPS/IPP.

What's relevant here is that we have a new requirement for sitelocal
mDNS:

 we need to signal via mDNS from the printer to the holder of the FQDN
zone (probably the CPE).   

-- 
Michael Richardson , Sandelman Software Works 



pgp6yyByM7jRk.pgp
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] a modest proposal

[Mark Andrews]

In message <201208011719.q71hjl6a007...@gateway.ipv6.occnc.com>, Curtis 
Villamizar writes:
> 
> In message 
> Mikael Abrahamsson writes:
>  
> > On Wed, 1 Aug 2012, Brian E Carpenter wrote:
> >  
> > > That's true. My point was that the CPE resolver will have to be upgraded 
> > > to support DNS64 for, and *only* for, IPv6-only hosts. How it knows 
> > > which hosts are IPv6-only is another mystery.
> >  
> > Indeed, I started a thread about this on v6ops the other day:
> >  
> > 
> >  
> > Seems there is no solution to this problem and I'm seem to be having 
> > trouble getting traction there that this might actually be a real problem 
> > that needs solving.
> 
> 
> Same answer as one given on that thread.  If a device can support
> IPv4, then use NAT4.  If a device can only support IPv6, then the
> DNS64 belongs on the IPv6-only device.  To that device all host return
>  records, since the A records are translated into ipv4-in-ipv6
> space.  The CPE should be dual stack and be capable of both NAT4 and
> NAT64 translations to allow reachability into the IPv4 world.  This is
> simple.  As pointed out on the thread, a patch has already been
> submitted to android and some 3gpp phone already do DNS64.
> 
> If the CPE doesn't do NAT64, the packet will wander along some route,
> most likely the default route, until it either hits a NAT64 or runs
> into a black hole.
> 
> Propogating DNS64 translated address can cause severe problems and
> therefore should never leak outside the single IPv6 only host that
> needs it to get to IPv4 addresses.  DNS64 and NAT64 already exist for
> BSD and Linux (bind and pf for BSD, bind and linuxnat64 for linux).

DNS64 does not add synthesised addresses to existing  RRsets.
IPv6-only nodes will not be able to connect to dual stack servers
as there is no IPv6 path.

> Curtis
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Reverse DNS

[Wouter Cloetens]

On 01/08/12 17:40, Andrew Sullivan wrote:

On Wed, Aug 01, 2012 at 04:58:42PM +0200, Wouter Cloetens wrote:

We assume that a DynDNS-style approach simply will never scale for
every IPv6 address in the home, and therefore the home router has to
be authoritative, handling the requests.


If I may ask, why do you make that assumption?  I assure you that Dyn
is running some very large zones with high change rates.  Now, it
might be that nobody would be willing to pay for such a service at the
rate Dyn would charge to make this profitable, assuming large numbers
of records and a high rate of change.  If that's your argument,
however, I'd like to know understand how this is going to be worth
doing for someone else when Dyn already has the sunk investment in
infrastructure.


Internet of Things. Home automation. 5, 10 years from now. 10k nodes 
low-power nodes for a site. (Not unrealistic for an office building, 
I've been told).
It is sensible to have those nodes visible in the DNS, forward and 
reverse, for remote management and other reasons. You basically never, 
ever want to type in an IPv6 address.
It is not sensible to have them register themselves to DynDNS, or have 
the router register to Dyn for them.


draft-mglt-homenet-naming-delegation and 
mglt-homenet-front-end-naming-delegation provide a solution that will 
work securely, out of the box, without any end user configuration at 
all, and consuming no bandwidth if the home DNS feature is not used. The 
end user doesn't even have to register for a DynDNS account.


*That* is what this WG should be about IMO; making things scale to 
unimaginable proportions (we are designing for the next 100 years), 
simple, without any need for configuration, and without cost.


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

Re: [homenet] Reverse DNS

[Ted Lemon]

On Aug 1, 2012, at 11:48 AM, Evan Hunt wrote:
>> What you understand as "crazy talk," I see as; trying to get something 
>> working, in best-effort mode, taking into account the limitations of a 
>> home network with a CE router in front of it.
> 
> Then again, the point of this WG as I understand it is to get rid of some
> of those limitations, not to accomodate or perpetuate them. :)

Exactly.   I think that the wish for an expedient solution often ignores the 
fact that a step-by-step implementation of the real solution isn't as hard as 
the proponents of expedient solutions often fear.

Regarding the question of whether to update the primary on the CPE device or 
update the primary on the ISP, the main motivation in my mind for doing it on 
the CPE device is that it avoids a massive key management problem.   If the CPE 
device is primary and the ISP device is secondary, the ISP can publish a SIG(0) 
key in a well-known zone and use that to authenticate zone transfers.   Going 
the other direction requires the ISP to have a public key somewhere for every 
single customer.   There's nothing fundamentally hard about this, but I think 
the other way is easier.

Having said that, of course we should describe how to do it both ways.   I just 
think the CPE being primary is going to be more popular, assuming both 
solutions are equally well-supported.

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

Re: [homenet] tunnels as way to disambiguate .local

[Evan Hunt]

> Do we want applications caching mDNS replies into configuration files?
> I think not, and I think the DNS people will shout loudly about that.

Hm... I'm a DNS people, but I'm not sure I object to this.  You'd want
some mechanism for clearing old records out after the devices had been
gone from the network for a long-enough time, but that's not intrinsically
hard.

> I regularly print to both my work and home printer remotely (yes, over
> IPv6. The CUPS server speaks IPv6 even if my home printer speaks only
> USB).

I'm of the opinion that "remote access from offsite" should be a service
you can configure your printer to provide, but which is not the default.

In my ideal world (please indulge me in a moment of handwaving), you plug
in your printer, and tell it what its name is (or let it pick its own
default such as "LaserPrinter-3"); it announces itself to the local network
as providing local printing, and its name is placed in the .sitelocal
domain.

*If* you check the box for "let the outside world print to me" -- which you
and I might want to do but most people wouldn't -- then it announces itself
as providing both local and remote printing, and its name is placed in
.sitelocal and then mirrored into the globally addressable domain that
you'd previously configured for your network: by preference, that would be
your private domain name, but if you don't have one of those then it could
mirror into a namespace controlled by your ISP, Apple, DynDNS or whatever.

If you were printing something, and you a found a printer via service
discovery which indicate that it could provide remote access, then you'd be
given the option to bookmark its global name and use it when you're away;
if it isn't configured for remote access then you woulnd't be given that
option.

A similar mental model could apply to the "fridge" and "lamp" examples
we've been kicking around as well -- you won't normally *want* them to be
globally accessible, but if you do, you should tell them so and let them
work it out with your network.  (This is the point I was trying to make at
the mic yesterday, but I'm not sure it came across.)

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Reverse DNS

[Evan Hunt]

> What you understand as "crazy talk," I see as; trying to get something 
> working, in best-effort mode, taking into account the limitations of a 
> home network with a CE router in front of it.

Then again, the point of this WG as I understand it is to get rid of some
of those limitations, not to accomodate or perpetuate them. :)

> We assume that a DynDNS-style approach simply will never scale for every 
> IPv6 address in the home, and therefore the home router has to be 
> authoritative, handling the requests.

You can have a router be authoritative for its own zones and also have
a reliable secondary name service elsewhere.

I run BIND 9 on my home router (netgear wndr3700 running customized 
openwrt/cerowrt, thank you Dave Taht); it's authoritative for several
zones, both forward and reverse, some of which are split into internal
and external views, and all of which are DNSSEC signed.  When any of
the zones is updated due to the addition or removal of a device, a
NOTIFY is sent to the secondary name service, which IXFRs up the
changes.  (I use ISC's SNS for this because I'm an employee and
get it for free, but there are similar inexpensive services out
there including, IIRC, a recent offering from Amazon -- and it
wouldn't be a difficult service for an ISP to offer.)

For queries originating inside my network, the router handles recursion
and will answer authoritatively when asked for a name in the site-local
namespace or in the internal view of the public namespaces.

Queries originating outside the network generally go to the secondary
servers.  If I'd wanted to, I could have configured my router to be a
hidden master, and then *all* the queries would go to the secondaries
(except for *XFR requests coming from the secondaries).

So in this model both the router and the secondary servers are
authoritative for the externally visible view of the network; the router
is solely authoritative for the internally visible view.  I don't know of
any reason this approach couldn't scale.

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] tunnels as way to disambiguate .local

[Curtis Villamizar]

In message <17002.1343839...@obiwan.sandelman.ca>
Michael Richardson writes:
 
>  
> > "Brian" =3D=3D Brian E Carpenter  writes:
> Brian> And therefore intrinsically evil, just like 10.0.0.0/8 is
> Brian> intrinsically evil.
>  
> Brian> IMHO we shouldn't be discussing how to make it work less
> Brian> badly; we should be discussing how to avoid it entirely.
>  
> Right, but we have installed base.
> Based upon comments in Jabber yesterday, I think that the right way is
> for fridge.local mDNS to return a series of SRV records in the
> additional information, one of which would contain a FQDN (having a GUA)
> for the fridge, if it had one.
>  
> I don't know exactly what that would look like, but it seems like the
> right process: discovery gives us a name, and the name is sometimes a
> FQDN.  That would also have solved Stuart's problem printing to
> bluehawaii, had his laptop CUPS bookmarked bluehawaii.apple.com rather
> than bluehawaii.local (nothing that bluehawaii.apple.com works just fine
> when in the office)
>  
> Michael Richardson , Sandelman Software Works=20


It might be reasonable for mDNS or dynamic DNS to populate the FQDN
with an A and  record and create a CNAME in local or sitelocal
that points to the FQDN.  Tools like host or dig would report the
CNAME, the FQDN, and the final A and/or  records if sitelocal was
in the search path before the domain.

I'm not sure how that works with CUPS bookmarking.

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

Re: [homenet] tunnels as way to disambiguate .local

[Michael Richardson]

> "Kerry" == Kerry Lynn  writes:
Kerry> Actually, I think the problem may be that CUPS insists on
Kerry> re-resolving the name every time it prints, rather than
Kerry> trying the GUA that it would have learned at initial
Kerry> discovery.

Do we want applications caching mDNS replies into configuration files?
I think not, and I think the DNS people will shout loudly about that.

Kerry> Nobody seems to be complaining about the need to be on-site
Kerry> to discover the service initially.  The issues seem to be

No, in fact, it's a feature.

Kerry> my desk, unless I connect my host to that same link.  I
Kerry> cannot remember a time when I needed to use it remotely.

I regularly print to both my work and home printer remotely (yes, over
IPv6. The CUPS server speaks IPv6 even if my home printer speaks only
USB).  I do this will all sorts of paperwork, receipts for online
expenses, etc.   Yes, I sometimes print to the wrong printer.
I also regularly print to these printers when "offline", knowing that
CUPS will punt it out when I get "home"

I believe that Google Cloud Print is getting close to eliminating my
need to own one of these infernal mechanical devices. 

Kerry> BTW, I agree with the earlier comment that the may be several
Kerry> good reasons to include VPN tunnels in the homenet
Kerry> architecture.

They exist. It would be nice if our secure setup protocol for homenet
could also be leveraged to setup remote access.

-- 
Michael Richardson , Sandelman Software Works 




pgpIVl0bSseGL.pgp
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Reverse DNS

[Mark Andrews]

In message <50194422.6070...@softathome.com>, Wouter Cloetens writes:
> On 01/08/12 16:13, Mark Andrews wrote:
> > In message<5018ddca.1010...@softathome.com>, Wouter Cloetens writes:
> >> On 01/08/12 03:26, Curtis Villamizar wrote:
> >>> Anything DNS related should be reliable.  Therefore a secondary would
> >>> be preferable to not having one.
> >>
> >> OTOH, the use case of a DNS lookup for a hostname or IP address for
> >> which the last-hop router is offline (at the time of the lookup) is 
> >> limited.
> >> It is there; e.g. batch log processing on web servers, but that is for
> >> informative purposes only, and doesn't cause connection failures.
> >
> > This is crazy talk.  We have absolutely no idea what will or will
> > not end up being run from the home.  Whether people will need to
> > lookup information about the home when it is unreachable or not.
> > How do you debug if you can reach home or not if you can't get the
> > addresses of the machines at home?
> 
> If you need to run a reliable service, you shouldn't be running it from 
> your home. The use case of homenet is restricted to that.

The only real difference between home and commercial is SLA agreements
and MTR.  Home is a perfectly fine place to run some services.  Some
services can only be run from the home.  Additionally PTR records
are not the only think that gets stored in the reverse DNS.

> What you understand as "crazy talk," I see as; trying to get something 
> working, in best-effort mode, taking into account the limitations of a 
> home network with a CE router in front of it.
> We assume that a DynDNS-style approach simply will never scale for every 
> IPv6 address in the home, and therefore the home router has to be 
> authoritative, handling the requests.

Actually dynamic DNS is extremely cheap and can scale to every
device.  Costs to host zones in volume are in single dollar digits
/ zone / year.  Automation reduces these costs towards the pure
hardware and comm costs which continue to drop.

> > The DNS was designed with the idea that there would be redundent
> > servers.  It is not designed to deal with not being able to connect
> > to any servers for a zone and it really does not work well when
> > this is the case.
> 
> If you *are* running a service from home, there is always the option of 
> setting up DynDNS specifically for those hosts that need to be accessible.
> -- 
> Architect Core Gateway   SoftAtHome R&D RGW  http://www.softathome.com/
> http://www.linkedin.com/in/wcloetens  Vaartdijk 3/B701, B-3018 Wijgmaal
> Tel: +32-16-852010  Mobile: +32-492-277790   Fax: +32-16-852099
> 
> This message and any attachments are confidential, intended solely for
> the addressees and are SoftAtHome’s ownership.
> Any unauthorized use or dissemination is prohibited. If you are not the
> intended addressee of this message, please cancel it immediately and
> inform the sender.
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] tunnels as way to disambiguate .local

[Curtis Villamizar]

In message <50193cab.5070...@gmail.com>
Brian E Carpenter writes:
 
> Synthesise a pseudo-TLD from the ULA prefix.
>  
> Brian

If the whole ULA is used, then the scope is single host.  If the ULA
prefix is used, then the scope is all reachable ULA which is the same
as sitelocal but with an obscure name.

Curtis

> On 01/08/2012 15:17, Curtis Villamizar wrote:
> > In message <5018d80c.90...@gmail.com>
> > Brian E Carpenter writes:
> >  
> >> 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
> > 
> > 
> > Brian,
> > 
> > Not being connected to the Internet and not having any configuration
> > at all might also be intrinsically evil, but that's the situation when
> > a consumer takes some gadget out of the box.
> > 
> > What we are trying to accomplish with the sitelocal is a way to name
> > things on a local network that have no domain name assigned through a
> > registry and have not had a domain name assigned as part of some
> > subdomain of the provider.
> > 
> > Even if the homenet WG was extremely thoroughthe gadget did 100% of
> > what we specify and implemented everything perfectly, we can't control
> > the user who almost never has a domain name of their own or the ISP
> > that can't be bothered delegating some subdomain of theirs to a
> > customer.  The customer then has no global domain to hang names off of
> > and has no choice but to not use DNS or make use of a sitelocal domain
> > with site local scope.
> > 
> > So sitelocal is inherently needed, either during a transition (until
> > the uplink comes up at least for the first time and a domain name is
> > learned) or permanently (if no domain name ever gets delegated to the
> > residential customer site).
> > 
> > Curtis
> > 
> > 
> > ps - Yes - it is inherently evil.  So is not delegating rDNS IMHO.
> >  But we can't control those MSO and ILEC residential ISPs.
___
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..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 . 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.. 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] a modest proposal

[Curtis Villamizar]

In message 
Mikael Abrahamsson writes:
 
> On Wed, 1 Aug 2012, Brian E Carpenter wrote:
>  
> > That's true. My point was that the CPE resolver will have to be upgraded 
> > to support DNS64 for, and *only* for, IPv6-only hosts. How it knows 
> > which hosts are IPv6-only is another mystery.
>  
> Indeed, I started a thread about this on v6ops the other day:
>  
> 
>  
> Seems there is no solution to this problem and I'm seem to be having 
> trouble getting traction there that this might actually be a real problem 
> that needs solving.


Same answer as one given on that thread.  If a device can support
IPv4, then use NAT4.  If a device can only support IPv6, then the
DNS64 belongs on the IPv6-only device.  To that device all host return
 records, since the A records are translated into ipv4-in-ipv6
space.  The CPE should be dual stack and be capable of both NAT4 and
NAT64 translations to allow reachability into the IPv4 world.  This is
simple.  As pointed out on the thread, a patch has already been
submitted to android and some 3gpp phone already do DNS64.

If the CPE doesn't do NAT64, the packet will wander along some route,
most likely the default route, until it either hits a NAT64 or runs
into a black hole.

Propogating DNS64 translated address can cause severe problems and
therefore should never leak outside the single IPv6 only host that
needs it to get to IPv4 addresses.  DNS64 and NAT64 already exist for
BSD and Linux (bind and pf for BSD, bind and linuxnat64 for linux).

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

Re: [homenet] tunnels as way to disambiguate .local

[Michael Richardson]

> "Brian" == Brian E Carpenter  writes:
Brian> And therefore intrinsically evil, just like 10.0.0.0/8 is
Brian> intrinsically evil.

Brian> IMHO we shouldn't be discussing how to make it work less
Brian> badly; we should be discussing how to avoid it entirely.

Right, but we have installed base.
Based upon comments in Jabber yesterday, I think that the right way is
for fridge.local mDNS to return a series of SRV records in the
additional information, one of which would contain a FQDN (having a GUA)
for the fridge, if it had one.

I don't know exactly what that would look like, but it seems like the
right process: discovery gives us a name, and the name is sometimes a
FQDN.  That would also have solved Stuart's problem printing to
bluehawaii, had his laptop CUPS bookmarked bluehawaii.apple.com rather
than bluehawaii.local (nothing that bluehawaii.apple.com works just fine
when in the office)

-- 
Michael Richardson , Sandelman Software Works 




pgpHS6xmlUqaH.pgp
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] tunnels as way to disambiguate .local

[Michael Thomas]

On 08/01/2012 12:17 AM, 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.



I think the implications of my note is that there really isn't anything that
needs to be done here. If you want to use naming that requires that you
be in some topology-defined boundary, then tunnel back to that network
if you're not there. VPN technology is pretty well understood, after all,
and there are probably a lot of reasons you might want to do that besides
naming.

That said, my interpretation of the requirements is that we want to do
something with names such that they are quasi-global, or truly global.
I'm inclined to agree that grafting those requirement onto .local is most
likely the road to madness.

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

Re: [homenet] Reverse DNS

[Andrew Sullivan]

On Wed, Aug 01, 2012 at 04:58:42PM +0200, Wouter Cloetens wrote:
> We assume that a DynDNS-style approach simply will never scale for
> every IPv6 address in the home, and therefore the home router has to
> be authoritative, handling the requests.

If I may ask, why do you make that assumption?  I assure you that Dyn
is running some very large zones with high change rates.  Now, it
might be that nobody would be willing to pay for such a service at the
rate Dyn would charge to make this profitable, assuming large numbers
of records and a high rate of change.  If that's your argument,
however, I'd like to know understand how this is going to be worth
doing for someone else when Dyn already has the sunk investment in
infrastructure.

Best,

A


-- 
Andrew Sullivan
a...@anvilwalrusden.com
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] section 3.2.2.1 of homenet-arch

[Curtis Villamizar]

In message <20120801082004.25b4c2329...@drugs.dv.isc.org>
Mark Andrews writes:
 
> In message <201208010333.q713xjub089...@gateway.ipv6.occnc.com>, Curtis 
> Villamizar writes:
> > 
> > In message <50181a1c.5050...@gmail.com>
> > Brian E Carpenter writes:
> >  
> > > On 31/07/2012 17:59, Michael Richardson wrote:
> > > >> "Brian" == Brian E Carpenter  writes:
> > > > >> I'm also surprised that we think we have to cope with flash 
> > > > renumbering
> > > > >> as a regular event, rather than a service-interrupting, ISP 
> > > > truck roll
> > > > >> catastrophy. 
> > > > 
> > > > Brian> But every time you reboot your antiquated v4-only CPE
> > > > Brian> and/or the antiquated 
> > > > Brian> v4-only PCs behind it, the PCs all get new IP addresses,
> > > > Brian> which may or
> > > > Brian> may not be the same as the previous time. There's nothing
> > > > Brian> new in flash 
> > > > Brian> renumbering for homenets. Not handling this would be a step
> > > > Brian> backwards.
> > > > 
> > > > Well... 
> > > > 
> > > > 1) sure, but the *customer* does this, not the ISP.
> > > > 2) the clients do have DHCP leases, and if they ask to renew their
> > > >previous IP, it usually gets honored.
> > >  
> > > It doesn't matter whether it's the user or the ISP that triggers a
> > > change, does it?
> > >  
> > > The point is, users don't care about this, except if they reach their
> > > shiny new wireless printer via its IP static address. There are
> > > definitely parts of draft-ietf-6renum-static-problem that apply here.
> > >  
> > >Brian
> > 
> > 
> > Brian,
> > 
> > Enterprise renumbering and homenet renumbering are generally quite
> > different.  Most homehets have short uptimes.  Most enterprises have
> > very long uptimes.  (insert favorite Microsoft reliability joke here).
>  
> Define short?  There are plenty of homes with equipment that isn't
> powered down every day and that has been up for months.

As long as the equipment is idle, an attempted renew on the DHCP lease
that fails won't hurt unless it causes something to hang.  Microsoft
has trained users to be used to power cycling things for no apparent
reason.

> I don't know about other but I maintain ssh connections for weeks
> from home to the main office at work.

I've been know to do that.  For long compiles I've learned to use
"nohup" and keep a log file that I can check on now and then.

> > If a renumbering is done right, there is an time when both the old and
> > new numbers are in use.  As in "ifconfig  inet6 newaddr
> > ... alias" in the *ix world.  During that transition time any use of
> > DHCP will hand out the new address.  Then comes a time when the leases
> > refuse to be renewed.  Then the old addresses go away.  This can be
> > day, weeks, or longer depending on the size of the transition.  During
> > that time a lot of "please reboot at least once ..." messages get
> > sent.
>  
> What's the dhcp stuff in the home?  RA's work fine here.  What is
> needed is a way to signal in the DNS to only use a deprecated address
> as a last resort measure.  Named to address and address to name
> mappings need to exist until after the address has ceased being
> used.

Below is what the CPE and host need to do.  The provider also needs to
keep around the old rDNS until the old address is no longer in use.
The provider needs to 1) grant new leases from the new number space,
2) request that users force a renew themselves in case there would be
any disruption, 3) allow time for users to force a renew, 4) force a
renew and refuse torenew the old leases, granting new ones (may be
disruptive to some), 4) allow more time, then completely get rid of
the old address space.

> > Today there is no DHCP help in avoiding the "please reboot" messages.
> > It should be possible for a DHCP client (ISC guys, are you out there?)
> > to do the following if a lease can't be renew and a new address is
> > provided:
> > 
> >   1.  Add the new address using an "ifconfig  ... alias"
> >   equivalent.
> > 
> >   2.  Check (using netstat -an equivalent) for use of the old address.
> >   Don't delete the old address if a socket still exists.
> > 
> >   3.  Periodically repeat step 2 until there is no connection using
> >   the old address.
> > 
> >   4.  Delete the old address using the equivalent of "ifconfig 
> >   ... -alias".
>  
> Actually you should be asking the OS vendors / distro maintainers
> to do this and send fixes to ISC.  This is all done in shell scripts
> that are highly customised to the client platform.  There isn't one
> linux script that works for all linux distros.
>  
> This also doesn't work for many udp based services.

You are right.  There are other retained IP addresses.  For example, a
DNS secondary might try to renew a lease based on the old address
until the primary name server DNS  entry TTL expires.  Perhaps a
minimum time in which there is no use of the old address 

Re: [homenet] Reverse DNS

[Wouter Cloetens]

On 01/08/12 16:13, Mark Andrews wrote:

In message<5018ddca.1010...@softathome.com>, Wouter Cloetens writes:

On 01/08/12 03:26, Curtis Villamizar wrote:

Anything DNS related should be reliable.  Therefore a secondary would
be preferable to not having one.


OTOH, the use case of a DNS lookup for a hostname or IP address for
which the last-hop router is offline (at the time of the lookup) is limited.
It is there; e.g. batch log processing on web servers, but that is for
informative purposes only, and doesn't cause connection failures.


This is crazy talk.  We have absolutely no idea what will or will
not end up being run from the home.  Whether people will need to
lookup information about the home when it is unreachable or not.
How do you debug if you can reach home or not if you can't get the
addresses of the machines at home?


If you need to run a reliable service, you shouldn't be running it from 
your home. The use case of homenet is restricted to that.


What you understand as "crazy talk," I see as; trying to get something 
working, in best-effort mode, taking into account the limitations of a 
home network with a CE router in front of it.
We assume that a DynDNS-style approach simply will never scale for every 
IPv6 address in the home, and therefore the home router has to be 
authoritative, handling the requests.



The DNS was designed with the idea that there would be redundent
servers.  It is not designed to deal with not being able to connect
to any servers for a zone and it really does not work well when
this is the case.


If you *are* running a service from home, there is always the option of 
setting up DynDNS specifically for those hosts that need to be accessible.


--
Architect Core Gateway   SoftAtHome R&D RGW  http://www.softathome.com/
http://www.linkedin.com/in/wcloetens  Vaartdijk 3/B701, B-3018 Wijgmaal
Tel: +32-16-852010  Mobile: +32-492-277790   Fax: +32-16-852099

This message and any attachments are confidential, intended solely for
the addressees and are SoftAtHome’s ownership.
Any unauthorized use or dissemination is prohibited. If you are not the
intended addressee of this message, please cancel it immediately and
inform the sender.
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] a modest proposal

[Curtis Villamizar]

In message <5018df5e.6040...@gmail.com>
Brian E Carpenter writes:
 
> On 31/07/2012 22:45, Curtis Villamizar wrote:
> > In message <5017d819.9030...@mtcc.com>
> > Michael Thomas writes:
> >  
> >> On 07/31/2012 01:00 AM, Brian E Carpenter wrote:
> >>> On 31/07/2012 01:20, Michael Thomas wrote:
>  On 07/30/2012 05:10 PM, Curtis Villamizar wrote:
> > If you see some advantage that solves the IPv4 address depletion (a
> > big point of the transition to IPv6 exercise), then I've missed it.
> > If so, please point out what I missed.
>  No, not at all and not the point. I'm just of the mind that if
>  we believe that v6 is really, really ready to go there shouldn't
>  be any problem in substituting rfc1918 v4 space with v6 ULA
>  space. If that modest change leads to trouble...
> >>> Well, it surely requires a DNS64 resolver in the CPE too.
> >>>
> >> Having embedded DNS functionality in the CPE is sort of a newish
> >> requirement, yes? If we think that's inevitable for real homenets,
> >> maybe this is a means of moving the ball forward?
> >>  
> >> Mike
> > 
> > 
> > This requirement is Not at all new.
> > 
> > Most low endish CPE get a single IPv4 address from the provider, do
> > NAT, offer PI addresses on the "home" side, offer themselves as DNS
> > resolvers on the home side.  Act as a DNS cache using the
> > nameserver(s) offerred by the service provider as forwarders.
> > 
> > Most home users get the CPE from the provider and the providers like
> > having a resolver in the CPE so today this is a business requirement,
> > not an IETF requirement.
>  
> That's true. My point was that the CPE resolver will have to be
> upgraded to support DNS64 for, and *only* for, IPv6-only hosts. How it
> knows which hosts are IPv6-only is another mystery.
>  
> Brian


Brian,

I was responding to the question:

> >> Having embedded DNS functionality in the CPE is sort of a newish
> >> requirement, yes?

Having DNS in the CPE is not a new requirement (at least in practice).

Extending the requirement to include DNS64 is new.

> How it knows which hosts are IPv6-only is another mystery.

I'm not if favor of using IPv4 in IPv6 and then having a NAT to turn
the IPv6 addresses into a single IPv4.  I agree with a prior comment
that this is complexity added with no significant gain.

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

Re: [homenet] section 3.2.2.1 of homenet-arch

[Curtis Villamizar]

In message <5018dd8a.2070...@gmail.com>
Brian E Carpenter writes:
 
> Excuse front posting, but...
>  
> > Today there is no DHCP help in avoiding the "please reboot" messages.
>  
> Don't RECONFIGURE (DHCPv6) and FORCERENEW (DHCP) cover this, in theory?
> They are unicast, which is a scaling issue in enterprise networks but
> presumably not in homenets.
>  
> Regards
>Brian


These only force a renew before the lease expires.  For the sometimes
very long IPv6 leases, this is essential.  For often relatively
shorter IPv4 leases, it is nice but not quite as essential.

The issue is not forcing the renew to occur earlier, it is the way in
which a renew that changes the address is handled.  Maybe its just
implementations taking a shortcut, but I think in practice changing
the IP address takes the interface down, kills all connections,
including listens, and then brings it back up with a new address.  Its
a bit like a reboot as implemented, except the user doesn't know its
coming and therefore may have open TCP connections that break.

What I've suggested is what to do on a renew that changes the address.
Add an alias.  Until the old address has no more connections or
listens on the old address, keep the old address.  Then remove the old
address.

If someone has an open connection, ssh for example, the old address
could be in use indefinitely, but if the transition is weeks, then its
unlikely to go beyond that.  For example, if someone was using ssh to
do a long compile on another machine, breaking the connection and
killing the compile would be bad.  There are certain to be plenty of
other uses of long duration TCP connections that would have to be
broken in this sort of transition, unless we can also extend TCP to
negotiate a change to one side of the address pair.

Curtis


> On 01/08/2012 04:33, Curtis Villamizar wrote:
> > In message <50181a1c.5050...@gmail.com>
> > Brian E Carpenter writes:
> >  
> >> On 31/07/2012 17:59, Michael Richardson wrote:
>  "Brian" == Brian E Carpenter  writes:
> >>> >> I'm also surprised that we think we have to cope with flash 
> >>> renumbering
> >>> >> as a regular event, rather than a service-interrupting, ISP truck 
> >>> roll
> >>> >> catastrophy. 
> >>>
> >>> Brian> But every time you reboot your antiquated v4-only CPE
> >>> Brian> and/or the antiquated 
> >>> Brian> v4-only PCs behind it, the PCs all get new IP addresses,
> >>> Brian> which may or
> >>> Brian> may not be the same as the previous time. There's nothing
> >>> Brian> new in flash 
> >>> Brian> renumbering for homenets. Not handling this would be a step
> >>> Brian> backwards.
> >>>
> >>> Well... 
> >>>
> >>> 1) sure, but the *customer* does this, not the ISP.
> >>> 2) the clients do have DHCP leases, and if they ask to renew their
> >>>previous IP, it usually gets honored.
> >>  
> >> It doesn't matter whether it's the user or the ISP that triggers a
> >> change, does it?
> >>  
> >> The point is, users don't care about this, except if they reach their
> >> shiny new wireless printer via its IP static address. There are
> >> definitely parts of draft-ietf-6renum-static-problem that apply here.
> >>  
> >>Brian
> > 
> > 
> > Brian,
> > 
> > Enterprise renumbering and homenet renumbering are generally quite
> > different.  Most homehets have short uptimes.  Most enterprises have
> > very long uptimes.  (insert favorite Microsoft reliability joke here).
> > 
> > If a renumbering is done right, there is an time when both the old and
> > new numbers are in use.  As in "ifconfig  inet6 newaddr
> > ... alias" in the *ix world.  During that transition time any use of
> > DHCP will hand out the new address.  Then comes a time when the leases
> > refuse to be renewed.  Then the old addresses go away.  This can be
> > day, weeks, or longer depending on the size of the transition.  During
> > that time a lot of "please reboot at least once ..." messages get
> > sent.
> > 
> > Today there is no DHCP help in avoiding the "please reboot" messages.
> > It should be possible for a DHCP client (ISC guys, are you out there?)
> > to do the following if a lease can't be renew and a new address is
> > provided:
> > 
> >   1.  Add the new address using an "ifconfig  ... alias"
> >   equivalent.
> > 
> >   2.  Check (using netstat -an equivalent) for use of the old address.
> >   Don't delete the old address if a socket still exists.
> > 
> >   3.  Periodically repeat step 2 until there is no connection using
> >   the old address.
> > 
> >   4.  Delete the old address using the equivalent of "ifconfig 
> >   ... -alias".
> > 
> > This would work for all client side connects that either were done
> > before the end of the transition period.  For home nets this covers
> > 99.something percent of the sites with no user intervention or reboot.
> > 
> > This requires no protocol change, just better coding in the DHCP
> > client software.
> > 
> > What th

Re: [homenet] tunnels as way to disambiguate .local

[Brian E Carpenter]

Synthesise a pseudo-TLD from the ULA prefix.

Brian

On 01/08/2012 15:17, Curtis Villamizar wrote:
> In message <5018d80c.90...@gmail.com>
> Brian E Carpenter writes:
>  
>> 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
> 
> 
> Brian,
> 
> Not being connected to the Internet and not having any configuration
> at all might also be intrinsically evil, but that's the situation when
> a consumer takes some gadget out of the box.
> 
> What we are trying to accomplish with the sitelocal is a way to name
> things on a local network that have no domain name assigned through a
> registry and have not had a domain name assigned as part of some
> subdomain of the provider.
> 
> Even if the homenet WG was extremely thoroughthe gadget did 100% of
> what we specify and implemented everything perfectly, we can't control
> the user who almost never has a domain name of their own or the ISP
> that can't be bothered delegating some subdomain of theirs to a
> customer.  The customer then has no global domain to hang names off of
> and has no choice but to not use DNS or make use of a sitelocal domain
> with site local scope.
> 
> So sitelocal is inherently needed, either during a transition (until
> the uplink comes up at least for the first time and a domain name is
> learned) or permanently (if no domain name ever gets delegated to the
> residential customer site).
> 
> Curtis
> 
> 
> ps - Yes - it is inherently evil.  So is not delegating rDNS IMHO.
>  But we can't control those MSO and ILEC residential ISPs.
> 
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] tunnels as way to disambiguate .local

[Curtis Villamizar]

In message <5018d80c.90...@gmail.com>
Brian E Carpenter writes:
 
> 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


Brian,

Not being connected to the Internet and not having any configuration
at all might also be intrinsically evil, but that's the situation when
a consumer takes some gadget out of the box.

What we are trying to accomplish with the sitelocal is a way to name
things on a local network that have no domain name assigned through a
registry and have not had a domain name assigned as part of some
subdomain of the provider.

Even if the homenet WG was extremely thoroughthe gadget did 100% of
what we specify and implemented everything perfectly, we can't control
the user who almost never has a domain name of their own or the ISP
that can't be bothered delegating some subdomain of theirs to a
customer.  The customer then has no global domain to hang names off of
and has no choice but to not use DNS or make use of a sitelocal domain
with site local scope.

So sitelocal is inherently needed, either during a transition (until
the uplink comes up at least for the first time and a domain name is
learned) or permanently (if no domain name ever gets delegated to the
residential customer site).

Curtis


ps - Yes - it is inherently evil.  So is not delegating rDNS IMHO.
 But we can't control those MSO and ILEC residential ISPs.
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Reverse DNS

[Mark Andrews]

In message <5018ddca.1010...@softathome.com>, Wouter Cloetens writes:
> On 01/08/12 03:26, Curtis Villamizar wrote:
> > Anything DNS related should be reliable.  Therefore a secondary would
> > be preferable to not having one.
> 
> OTOH, the use case of a DNS lookup for a hostname or IP address for 
> which the last-hop router is offline (at the time of the lookup) is limited.
> It is there; e.g. batch log processing on web servers, but that is for 
> informative purposes only, and doesn't cause connection failures.

This is crazy talk.  We have absolutely no idea what will or will
not end up being run from the home.  Whether people will need to
lookup information about the home when it is unreachable or not.
How do you debug if you can reach home or not if you can't get the
addresses of the machines at home?

The DNS was designed with the idea that there would be redundent
servers.  It is not designed to deal with not being able to connect
to any servers for a zone and it really does not work well when
this is the case.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] section 3.2.2.1 of homenet-arch

[Mark Andrews]

In message <201208010333.q713xjub089...@gateway.ipv6.occnc.com>, Curtis 
Villamizar writes:
> 
> In message <50181a1c.5050...@gmail.com>
> Brian E Carpenter writes:
>  
> > On 31/07/2012 17:59, Michael Richardson wrote:
> > >> "Brian" == Brian E Carpenter  writes:
> > > >> I'm also surprised that we think we have to cope with flash 
> > > renumbering
> > > >> as a regular event, rather than a service-interrupting, ISP truck 
> > > roll
> > > >> catastrophy. 
> > > 
> > > Brian> But every time you reboot your antiquated v4-only CPE
> > > Brian> and/or the antiquated 
> > > Brian> v4-only PCs behind it, the PCs all get new IP addresses,
> > > Brian> which may or
> > > Brian> may not be the same as the previous time. There's nothing
> > > Brian> new in flash 
> > > Brian> renumbering for homenets. Not handling this would be a step
> > > Brian> backwards.
> > > 
> > > Well... 
> > > 
> > > 1) sure, but the *customer* does this, not the ISP.
> > > 2) the clients do have DHCP leases, and if they ask to renew their
> > >previous IP, it usually gets honored.
> >  
> > It doesn't matter whether it's the user or the ISP that triggers a
> > change, does it?
> >  
> > The point is, users don't care about this, except if they reach their
> > shiny new wireless printer via its IP static address. There are
> > definitely parts of draft-ietf-6renum-static-problem that apply here.
> >  
> >Brian
> 
> 
> Brian,
> 
> Enterprise renumbering and homenet renumbering are generally quite
> different.  Most homehets have short uptimes.  Most enterprises have
> very long uptimes.  (insert favorite Microsoft reliability joke here).

Define short?  There are plenty of homes with equipment that isn't
powered down every day and that has been up for months.

I don't know about other but I maintain ssh connections for weeks
from home to the main office at work.

> If a renumbering is done right, there is an time when both the old and
> new numbers are in use.  As in "ifconfig  inet6 newaddr
> ... alias" in the *ix world.  During that transition time any use of
> DHCP will hand out the new address.  Then comes a time when the leases
> refuse to be renewed.  Then the old addresses go away.  This can be
> day, weeks, or longer depending on the size of the transition.  During
> that time a lot of "please reboot at least once ..." messages get
> sent.

What's the dhcp stuff in the home?  RA's work fine here.  What is
needed is a way to signal in the DNS to only use a deprecated address
as a last resort measure.  Named to address and address to name
mappings need to exist until after the address has ceased being
used.

> Today there is no DHCP help in avoiding the "please reboot" messages.
> It should be possible for a DHCP client (ISC guys, are you out there?)
> to do the following if a lease can't be renew and a new address is
> provided:
> 
>   1.  Add the new address using an "ifconfig  ... alias"
>   equivalent.
> 
>   2.  Check (using netstat -an equivalent) for use of the old address.
>   Don't delete the old address if a socket still exists.
> 
>   3.  Periodically repeat step 2 until there is no connection using
>   the old address.
> 
>   4.  Delete the old address using the equivalent of "ifconfig 
>   ... -alias".

Actually you should be asking the OS vendors / distro maintainers
to do this and send fixes to ISC.  This is all done in shell scripts
that are highly customised to the client platform.  There isn't one
linux script that works for all linux distros.

This also doesn't work for many udp based services.

> This would work for all client side connects that either were done
> before the end of the transition period.  For home nets this covers
> 99.something percent of the sites with no user intervention or reboot.
> 
> This requires no protocol change, just better coding in the DHCP
> client software.
> 
> What this does not cover is a service that is listenning on a well
> known port.  This is rare among home nets (except for homes of readers
> of IETF lists) but very common among enterprises.

At the moment.  There is no good reason to not be listening on
standard ports if you want to provide your own servers within the
home.  DNS will almost certainly be done if only to as hidden
masters.  Just publish your current addresses in the DNS and they
can be reached.  Cable and DSL are always on services.  Homes are
no longer dialup.

> Many points made about license servers, etc in
> draft-ietf-6renum-static-problem don't apply to home nets.
> 
> Renumbering an enterprise is doable.  Renumbering my home net has been
> quite easy.  I've done it a few times already and I'm sure will have
> to again.  The procedure suggested above is just done manually.
> 
> One hint is that on BSD and Linux at least a "netstat -an" should
> reveal any listens on old addresses.  An automated scan on an
> enterprise network can identify servers and services needing a
> reconfi

Re: [homenet] a modest proposal

[Mikael Abrahamsson]

On Wed, 1 Aug 2012, Brian E Carpenter wrote:

That's true. My point was that the CPE resolver will have to be upgraded 
to support DNS64 for, and *only* for, IPv6-only hosts. How it knows 
which hosts are IPv6-only is another mystery.


Indeed, I started a thread about this on v6ops the other day:



Seems there is no solution to this problem and I'm seem to be having 
trouble getting traction there that this might actually be a real problem 
that needs solving.


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

Re: [homenet] section 3.2.2.1 of homenet-arch

[Brian E Carpenter]

On 31/07/2012 19:23, Michael Richardson wrote:
>> "Brian" == Brian E Carpenter  writes:
> Brian> But every time you reboot your antiquated v4-only CPE and/or the 
> antiquated
> Brian> v4-only PCs behind it, the PCs all get new IP addresses, which may 
> or
> Brian> may not be the same as the previous time. There's nothing new in 
> flash
> Brian> renumbering for homenets. Not handling this would be a step
> Brian> backwards.
> 
> >> Well... 
> >> 
> >> 1) sure, but the *customer* does this, not the ISP.
> >> 2) the clients do have DHCP leases, and if they ask to renew their
> >> previous IP, it usually gets honored.
> 
> Brian> It doesn't matter whether it's the user or the ISP that triggers
> Brian> a change, does it?
> 
> It does.
> When the customer power cycles their device, everything starts again.
> They know they did this.
> 
> If the ISP renegs on the lifetimes of the leases, and wants to flash
> renumber the customer, either:
>   a) there is protocol for forcing the renumbering (does 6renum provide
>  this?)

I already mentioned RECONFIGURE (DHCPv6) and FORCERENEW (DHCP). Whatever
we adopt for prefix delegation needs the equivalent.

>   b) the customer is offline until *they* reboot their device.
> 
> Brian> The point is, users don't care about this, except if they reach 
> their
> Brian> shiny new wireless printer via its IP static address. There are 
> definitely
> Brian> parts of draft-ietf-6renum-static-problem that apply here.
> 
> okay, I'll read it.
> But, the printer is addressed as "printer.local", and is reached with
> the ULA, and we agreed that having this work regardless of whether or
> not the ISP was alive was in-scope.

Sure, except IMHO the printer should have an unambiguous FQDN and we need
dynamic DNS updates, just in case.

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

Re: [homenet] a modest proposal

[Brian E Carpenter]

On 31/07/2012 22:45, Curtis Villamizar wrote:
> In message <5017d819.9030...@mtcc.com>
> Michael Thomas writes:
>  
>> On 07/31/2012 01:00 AM, Brian E Carpenter wrote:
>>> On 31/07/2012 01:20, Michael Thomas wrote:
 On 07/30/2012 05:10 PM, Curtis Villamizar wrote:
> If you see some advantage that solves the IPv4 address depletion (a
> big point of the transition to IPv6 exercise), then I've missed it.
> If so, please point out what I missed.
 No, not at all and not the point. I'm just of the mind that if
 we believe that v6 is really, really ready to go there shouldn't
 be any problem in substituting rfc1918 v4 space with v6 ULA
 space. If that modest change leads to trouble...
>>> Well, it surely requires a DNS64 resolver in the CPE too.
>>>
>> Having embedded DNS functionality in the CPE is sort of a newish
>> requirement, yes? If we think that's inevitable for real homenets,
>> maybe this is a means of moving the ball forward?
>>  
>> Mike
> 
> 
> This requirement is Not at all new.
> 
> Most low endish CPE get a single IPv4 address from the provider, do
> NAT, offer PI addresses on the "home" side, offer themselves as DNS
> resolvers on the home side.  Act as a DNS cache using the
> nameserver(s) offerred by the service provider as forwarders.
> 
> Most home users get the CPE from the provider and the providers like
> having a resolver in the CPE so today this is a business requirement,
> not an IETF requirement.

That's true. My point was that the CPE resolver will have to be upgraded
to support DNS64 for, and *only* for, IPv6-only hosts. How it knows
which hosts are IPv6-only is another mystery.

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

Re: [homenet] Reverse DNS

[Wouter Cloetens]

On 01/08/12 03:26, Curtis Villamizar wrote:

Anything DNS related should be reliable.  Therefore a secondary would
be preferable to not having one.


OTOH, the use case of a DNS lookup for a hostname or IP address for 
which the last-hop router is offline (at the time of the lookup) is limited.
It is there; e.g. batch log processing on web servers, but that is for 
informative purposes only, and doesn't cause connection failures.

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

Re: [homenet] section 3.2.2.1 of homenet-arch

[Brian E Carpenter]

Excuse front posting, but...

> Today there is no DHCP help in avoiding the "please reboot" messages.

Don't RECONFIGURE (DHCPv6) and FORCERENEW (DHCP) cover this, in theory?
They are unicast, which is a scaling issue in enterprise networks but
presumably not in homenets.

Regards
   Brian

On 01/08/2012 04:33, Curtis Villamizar wrote:
> In message <50181a1c.5050...@gmail.com>
> Brian E Carpenter writes:
>  
>> On 31/07/2012 17:59, Michael Richardson wrote:
 "Brian" == Brian E Carpenter  writes:
>>> >> I'm also surprised that we think we have to cope with flash 
>>> renumbering
>>> >> as a regular event, rather than a service-interrupting, ISP truck 
>>> roll
>>> >> catastrophy. 
>>>
>>> Brian> But every time you reboot your antiquated v4-only CPE
>>> Brian> and/or the antiquated 
>>> Brian> v4-only PCs behind it, the PCs all get new IP addresses,
>>> Brian> which may or
>>> Brian> may not be the same as the previous time. There's nothing
>>> Brian> new in flash 
>>> Brian> renumbering for homenets. Not handling this would be a step
>>> Brian> backwards.
>>>
>>> Well... 
>>>
>>> 1) sure, but the *customer* does this, not the ISP.
>>> 2) the clients do have DHCP leases, and if they ask to renew their
>>>previous IP, it usually gets honored.
>>  
>> It doesn't matter whether it's the user or the ISP that triggers a
>> change, does it?
>>  
>> The point is, users don't care about this, except if they reach their
>> shiny new wireless printer via its IP static address. There are
>> definitely parts of draft-ietf-6renum-static-problem that apply here.
>>  
>>Brian
> 
> 
> Brian,
> 
> Enterprise renumbering and homenet renumbering are generally quite
> different.  Most homehets have short uptimes.  Most enterprises have
> very long uptimes.  (insert favorite Microsoft reliability joke here).
> 
> If a renumbering is done right, there is an time when both the old and
> new numbers are in use.  As in "ifconfig  inet6 newaddr
> ... alias" in the *ix world.  During that transition time any use of
> DHCP will hand out the new address.  Then comes a time when the leases
> refuse to be renewed.  Then the old addresses go away.  This can be
> day, weeks, or longer depending on the size of the transition.  During
> that time a lot of "please reboot at least once ..." messages get
> sent.
> 
> Today there is no DHCP help in avoiding the "please reboot" messages.
> It should be possible for a DHCP client (ISC guys, are you out there?)
> to do the following if a lease can't be renew and a new address is
> provided:
> 
>   1.  Add the new address using an "ifconfig  ... alias"
>   equivalent.
> 
>   2.  Check (using netstat -an equivalent) for use of the old address.
>   Don't delete the old address if a socket still exists.
> 
>   3.  Periodically repeat step 2 until there is no connection using
>   the old address.
> 
>   4.  Delete the old address using the equivalent of "ifconfig 
>   ... -alias".
> 
> This would work for all client side connects that either were done
> before the end of the transition period.  For home nets this covers
> 99.something percent of the sites with no user intervention or reboot.
> 
> This requires no protocol change, just better coding in the DHCP
> client software.
> 
> What this does not cover is a service that is listenning on a well
> known port.  This is rare among home nets (except for homes of readers
> of IETF lists) but very common among enterprises.
> 
> Many points made about license servers, etc in
> draft-ietf-6renum-static-problem don't apply to home nets.
> 
> Renumbering an enterprise is doable.  Renumbering my home net has been
> quite easy.  I've done it a few times already and I'm sure will have
> to again.  The procedure suggested above is just done manually.
> 
> One hint is that on BSD and Linux at least a "netstat -an" should
> reveal any listens on old addresses.  An automated scan on an
> enterprise network can identify servers and services needing a
> reconfig and a service restart without any system reboot.  [ Microsoft
> systems may need to reboot or power down and remove the CMOS battery
> from the motherboard or maybe buy new hardware.  :-) ]
> 
>>> In IPv6 space, the host part will generally stay the same (modulo
>>> privacy extensions, which are default on for some clients).  We've said
>>> that the ULA ought to stay the same, so in fact, I agree, the internal
>>> addresses actually all stay the same.
>>>
>>> I'm still surprised that an ISP will need to flash renumber faster than
>>> it can just expire leases.  If it's just repartitioning of network to
>>> deal with growth, that ought to be predictable and prefix lifetimes can
>>> be reduced in advance.  
>>>
>>> If it's actually some equipment failing, resulting in service
>>> interruptions, and then restoration by rewiring the network... then I
>>> understand.  
> 
___
homenet mailing list

Re: [homenet] tunnels as way to disambiguate .local

[Brian E Carpenter]

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