Subject: [homenet] section 3.2.2.1 of homenet-arch

From: Michael Richardson <[email-masked]>
Date: Mon, 30 Jul 2012 19:06:56 -0400

I read arch-04.

I want to suggest some minor changes to section 3.2.2.1.
First, we have 8 IPv6 Hosts, can we number/name them H1 through H8?
Second, H3 and H4 have, I guess, two network interfaces, can we number them
as H3.B, H3.E and H4.B/H4.E.
(Diagrams in section 3.2.2.2 should number their hosts too. I don't know
if they should be H9-H12, or H1-H4)

The top label for Network B/E should say instead "Network B(E)"
and the bottom label for Network B/E should say instead "Network E(B)"
I suggest labelling the link from CER to Internal Router as "Link F"
(or Network F)

I wonder if we should identify architectural statements as numbered
requirements. This doesn't have to imply that we write things in a list
form.

I suggest adding this text to 3.2.2.1, after the diagram;

====

In this diagram there is one CER.  It has a single uplink interface.
It has three additional interfaces connected to
Network A, Link F, and Network B.  IPv6 Internal Router (IR) has four
interfaces connected to Link F, Network C, Network D and Network E.
Network B and Network E have been bridged, likely inadvertedly. This
could be as a result of connecting a wire between a switch for Network B
and a switch for Network E.

Any of logical Networks A through F might be wired or wireless. 
Where multiple hosts are shown, this might be through one or more
physical ports on the CER or IPv6 (IR), wireless networks, or through
one or more layer-2 only ethernet switches.

====

page 21, paragraph 2, "the internal operation": s/should/SHOULD/
section 3.4.2 as well.
oh, wait.  no RFC2119 text at all.  Is it inappropriate for an
architecture to state requirements in 2119 language?

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.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 31 Jul 2012 08:49:02 +0100

On 31/07/2012 00:06, Michael Richardson wrote:

...
> as a regular event, rather than a service-interrupting, ISP truck roll

But every time you reboot your antiquated v4-only CPE and/or the antiquated
v4-only PCs behind it, the PCs all get new IP addresses, which may or
may not be the same as the previous time. There's nothing new in flash
renumbering for homenets. Not handling this would be a step backwards.

Homenets are out of scope for 6renum, but there will be considerable
overlap.

    Brian

---

From: Michael Richardson <[email-masked]>
Date: Tue, 31 Jul 2012 12:59:19 -0400

>>>>> "Brian" == Brian E Carpenter <Brian> 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.

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.  

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works 
IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 31 Jul 2012 18:47:08 +0100

>    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

---

From: Michael Richardson <[email-masked]>
Date: Tue, 31 Jul 2012 14:23:02 -0400

>> 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?)
  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.

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 31 Jul 2012 23:33:45 -0400

In message <[email-masked]>
Brian E Carpenter writes:
 
> >     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 
> It doesn't matter whether it's the user or the ISP that triggers a
> change, does it?
>  
> 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 <intf> 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 <intf> ... 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 <intf>
      ... -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.  :-) ]