Subject: Re: [homenet] automatic prefix management (OSPF or ISIS version)

From: "Fred Baker (fred)" <[email-masked]>
Date: Fri, 22 Feb 2013 04:50:05 +0000

On Feb 22, 2013, at 1:54 PM, Michael Richardson <[email-masked]> wrote:

> For a network where there is more than one ISP, is it acceptable for a CPE that has decided that it is PREFIX1:0123::/64, to "randomly" decide to be PREFIX2:0123::/64?

I don't see why not, at least in the home.

There is a case, which homenet hasn't thought much about that I'm aware of, which is renumbering a network. You'll notice in my draft that if the autoconfig prefix is withdrawn, I expect prefixes dependent on it to be withdrawn, and if stored in permanent storage, erased. The implication is that if the same prefix is then readvertised, there's a good chance that all of the subnet numbers will change. I know of at least one scenario where that would be considered a desirable characteristic. But I don't think that case is, at least at this point, a general case or one I would specify beyond a "MAY".

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 22 Feb 2013 08:22:35 +0000

On 22/02/2013 04:50, Fred Baker (fred) wrote:
>> For a network where there is more than one ISP, is it
>> acceptable for a CPE that has decided that it is
>> PREFIX1:0123::/64, to "randomly" decide to be
>> PREFIX2:0123::/64?
> 
> There is a case, which homenet hasn't thought much about that
> I'm aware of, which is renumbering a network. 

Surely, in a homenet, it's very much the case that (as Fred has
hinted over in 6renum) the issue is "numbering" rather than
renumbering. I may be too much of an energy conservation nut for
most people, but my homenet is cold-started and numbered most
mornings, because it is powered off at bedtime.

However, I can see no harm in sticky subnet numbering, as long
as the new prefix isn't long enough to overwrite the old subnet
numbers.

> You'll notice
> in my draft that if the autoconfig prefix is withdrawn, I
> expect prefixes dependent on it to be withdrawn, and if
> stored in permanent storage, erased. The implication is that
> if the same prefix is then readvertised, there's a good
> chance that all of the subnet numbers will change. I know of
> at least one scenario where that would be considered a
> desirable characteristic. But I don't think that case is, at
> least at this point, a general case or one I would specify
> beyond a "MAY". 

Actually, do you even need a formal "MAY"? It's an implementer
choice, isn't it?

  Brian

---

From: Michael Richardson <[email-masked]>
Date: Fri, 22 Feb 2013 09:18:31 -0500

>>>>> "fred" == fred  <Baker (fred)" <[email-masked]>> writes:
    fred> my draft that if the autoconfig prefix is withdrawn, I expect
    fred> prefixes dependent on it to be withdrawn, and if stored in
    fred> permanent storage, erased. The implication is that if the same
    fred> prefix is then readvertised, there's a good chance that all of
    fred> the subnet numbers will change. I know of at least one
    fred> scenario where that would be considered a desirable
    fred> characteristic. But I don't think that case is, at least at
    fred> this point, a general case or one I would specify beyond a
    fred> "MAY". 

Assuming that the random "seed" is not erased, or that another prefix
has been announced before the original withdrawn, then the seed might
persist.   (Remember that ULA prefix...)

Can you elaborate the scenario where a subnet-id renumbering would be
desireable, and would we want to actually signal this situation
explicitely?

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Fri, 22 Feb 2013 17:17:49 +0000

On Feb 23, 2013, at 3:18 AM, Michael Richardson <[email-masked]>
 wrote:

> Can you elaborate the scenario where a subnet-id renumbering would be desireable, and would we want to actually signal this situation explicitly?

There is a BAA (a request for a research proposal) from the US Air Force for a technology or methodology that would enable a network to "morph under attack." A presumably-related question came to me a couple of years ago from a researcher at Johns Hopkins APL; she wondered whether it would be possible for a network to blunt a DDOS attack without betraying the information that the attack had been detected.

One way that *could* work would be to have the network periodically renumber. Imagine the network as a whole, or individual LANs from time to time, adding a prefix, making the old one "not preferred", and then removing the old one a few minutes later. The network endures the attack for a little while and then - not because it has detected an attack, but because it would do so anyway - side-steps it in routing.

I'm imagining the operators in the room giggling to themselves at this point, or tearing their hair before running screaming from the "room". One would not want to have to debug anything in such a network.

But that's what I'm referring to. I can imagine a network that, by policy, actively wants the algorithm to choose a new number.