North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: IPV6 renumbering painless?

  • From: Henning Brauer
  • Date: Sat Nov 13 04:11:56 2004

* Owen DeLong <[email protected]> [2004-11-13 09:11]:
> Or... Recognizing that you have a dependency on DNS, you include
> S10WaitForDns in your rc3.d and don't continue the bootstrap until
> DNS is reachable.

in my what? ;)
this is just sick, in any case.

> >>> Not to forget all the IP address based ACLs.
> >>I suspect that eventually, we will discover that ADDRESS-based
> >>ACLs simply do not scale to a V6 world, and, you will see support
> >>for other strategies, such as host-name based ACLs.
> >Layer 3 doesn't know host names. Nor does layer 4. Applications do.
> >Security requirements do often mandate working access control even
> >when DNS doesn't work or is compromised.
> Security requirements are that you not permit packets that should not be
> when DNS is not working.  Nothing says the router cannot run a resolver
> pass when parsing the ACL or when told to refresh the ACL to translate
> the configured names into IP addresses.  Nothing precludes a periodic
> automatic refresh.

this is completely unacceptable and fails the point entirely.

> Hope this helps show that these problems can be mitigated in more
> scalable ways.

why do the v6 proponents always pretend that they can change everything?
there's a reason for how things are now, and many of them are good 
reasons (and some are poor, yes).
v6 should solve
1) the address space problem
2) autoconfiguation

however, by giving this to academics with much too much time on their 
hands, v6 transformed into unusable crap, and we are where we are now, 
as in, no real world relevance for v6, and it doesn't look like that 
will change anytime soon.

face some facts, you are not going to change the way the net works in 
such ways.

go back to the drawing board and start cutting out the crap. then v6 
(or whatever it might be called then) has a chance.