Markku Savela [mailto:[EMAIL PROTECTED] wrote:

> > From: "Jeroen Massar" <[EMAIL PROTECTED]>
> > Markku Savela [mailto:[EMAIL PROTECTED] wrote:
> > > Despite claims of opposite, this combination works just fine.
> > 
> > Example.com: fec0::/10
> > Example.org: fec0::/10
> > 
> > Good luck in tossing the bits around to routers in between 
> those sites
> > :)
> 
> That would happen only if both sites merged into single site. If sites
> are just connected via global internet
> 
> 
>  example.com               example.org
>          |
> Site-A --|                |
>          |---- INTERNET---|
>                           |-- Site-B
> 
> 
> If a host at example.com resolves xxx.example.org, it will not get
> fec0::/10 address as reply. It will get some global address of site-B.

Global addresses, good, and where did you need a SL for again?

> 
> Yes, you need two-faced DNS, but again, this is standard practise
> today. Banning sitelocals will not kill two-faced DNS.

They used to walk from europe to isreal for the crusades?
Do you really think that current armies will walk all that way?
Times change, so does the internet.

Also why should 'banning' sitelocals 'kill' two-faced DNS?
Two faced DNS is just a way of showing a specific namespace
to a specific set of clients. Or for some people security
through obscurity.

> However, a "merger", without global addresses and renumbering, would
> look as
> 
>  example.com   example.org
>          |
> Site-A --|       |
>          |--GW---|
>                  |-- Site-B
> 
> Now, if site-A and site-b previously used different prefixes, like
> "fec0:site:aaaa" and "fec0:site:bbbb", then merger is trivial (GUPI,
> anyone?)

And SL hasn't got any GUPI or unique addresses in it's current form.
Thats why the *current* form should be deprecated and a better way
for solving this kind of problem should be found out.
 
> However, if they used overlapping fec0:: prefixes, yes, simplest would
> be to renumber one of the sites.

Have fun renumbering ;)

> [Although, I could also make it work with overlapping addresses as is,
> but it does require a revision to the way name resolving is done--I
> have this implemented, but I would not expect everyone to do it. The
> solution does get a bit too complex to explain here. The solution is
> designed to handle multiple overlapping IPv4 private address spaces,
> so IPv6 sitelocal would be a no-brainer for it :-].

Which breaks end-to-end connectivity. Where did you need SL for again?

> > Not even speaking about when you have internal webservers:
> > 
> > www.example.com fec0::1
> > www.example.org fec0::1
> 
> Well, unless sites are truly merged, accessing "internal" servers from
> another site is not supposed to happen anyway.

Then why merge in the first place?

> > What you need is a globally unique /48 that is disconnected
> > and which one should be able to register 'cheaply'. Eg
> > an annual fee of E20 or something just to make sure that
> > not everybody starts harvesting them.
> 
> Why should I pay anything? I have a small net at home with few hosts,
> but connected to the internet. I just pick some random address, for
> example starting with "fec0:/10".. :-).

Indeed 'just pick some random address' if you don't want to
be connected to the rest of the world. No need for SL.
Also E20 or a similar amount is peanuts compared to what it
would cost if you need to renumber your complete site.

> Big organisations do not need IPv6 at all. Their internal networks run
> quite happily using IPv4 private address spaces. As I said earlier,
> system admins wont allow globally routable addresses for the internal
> nodes anyway.

Great, if they don't need IPv6, where did we need SL for again?

> IPv6 is needed by millions of private homes getting connected to the
> internet and needing global addresses. And, it is needed by millions
> of mobile phones that want to run E2E applications, which need global
> addresses.

Indeed global addresses. Where did the need for SL go again?

Still no reason for keeping SL's...

Greets,
 Jeroen


--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------

Reply via email to