ietf
[Top] [All Lists]

Re: Deployment vs the IPv6 community's ambivalence towards large providers

2000-08-17 18:10:02
Matt Crawford writes:

| Sean, you knowingly and deliberately wasted people's time all week
| with your nonsensical suggestions (as evidenced by your first
| message's label "Fuel for the B Ark") ... and you now want us to
| believe that you're upset by being told that you're wasting our time?

I'm not upset at all.  I am merely pointing out that there
is a major cultural rift between IPv6-Lovers, a group which
includes precious few ISPs of ANY variety, and IPv6-Haters
which interestingly is subscribed to by a large number of people
who are involved with engineering major transit backbones and
other networks, and the vendor-engineers who support them.

This spill-over on the IETF mailing list is no different than
what happens in person.

As to my intervention: it was not a complete waste of time, and
led to some interesting off-list discussions about how to manage
IPv6-based VPNs.  I excerpt a little from three such messages
below, so you can better reinforce in your own mind your claim of the
"nonsensical" nature of my suggestions.

| There are people who play the "troll" game a lot better.  They
| practice it in various newsgroups.  Occasionally they've tried to
| bring it to the IETF list, to nobody's satisfaction.  Maybe you'd
| enjoy playing in their sandbox.  Go, make us proud.

Gosh, your halo is really impressive.  Where can I buy one?
I'd like to be just as sweet and innocent as you someday.

Meanwhile, the fuel caught fire beautifully when your lot 
from the B Ark saw "VPN that is subscribed to on the basis 
of kid-safeness" and claimed that it simply cannot be done 
at all, with little to no basis for such a claim, and then
proceeded to shoot-the-messenger, which you do so well.

I suspect that,if I (or perhaps someone who is not on IPv6-Haters)
had started with the examples below rather than with a "kid-safe"
one, the lot of you would say, "great idea! and IPv6 makes it easier!".

I am sure the irony is not lost on anyone.

        Sean.

- --
| come on. every dinky corner church here in 
| the us has its own view of what is and is not 
| moral, what is acceptable
| - for children,
| - for adults,
| - for men
| - for women
| - etc
| we have no shortage, either in the us or worldwide,
| of people who Know what the True Rightous Path
| really is... each will want their own vpn.

All of this aggregates really well under "specific dinky corner church".
Thus, one globally-visible prefix for each "dinky corner church", the
address space of which is subnetted internally along the lines above.

Try s/specific dinky corner church/Apple/ and then categories
       - for sales & marketing
       - for engineering
       ...

| Each vpn is its own aggregate, right?
| Each aggregate has to appear in the routing tables
| (probably each /128 address since the endpoints of
| the aggregate are spread out all over the place).

The aggregate does, the /128s DO NOT because the path TOWARDS
the individual /128s are THROUGH the points which advertise
the aggregate.   Thus traffic TO the /128s must pass through
the "choke points";
- --
| >So, "kid-safe" and "perry-porn" rendezvous-points might be topologically
| >adjacent, and therefore can be aggregated into a single prefix with
| >respect to the global routing system.   
| >
| >The range of addresses which is "kid-safe" has to be known to the
| >host trying to see only kid-safe stuff, but the knowledge does NOT
| >come from the routing system.
|
| but kid-safe is a different prefix than perry-porn, right?
| therefore routing has to know about the prefix.

No!  No more than the describing *.lcs.mit.edu (18.26/16 or so)
and the range describing *.media.mit.edu (18.85/16 or so) and
so forth are described to the outside world in a non-aggregated
fashion.   Each of these (mutually hostile :) ) IPv4 addresses
are advertised in one topological location, in the aggregate 18/8.

Consider a host somewhere else in the Internet, with an address
192.192.192.192 that has an IP-in-IP tunnel interface that is
the target of a tunnel from a router inside *.lcs.mit.edu.
Any traffic sent to 18.26.26.26 arrives on a router inside
the "MIT-LCS VPN", whereupon that router immediately wrapps
an GRE header around the entire packet, with the GRE packet's
destination address set to 192.192.192.192.   When final host
receives the GRE packet, it decapsulates it, and examines
the destination address of the tunnelled packet.  The final
host knows it is 18.26.26.26, and therefore processes it locally.

Yes, it means inefficient routing - a host elsewhere in Taiwan
may end up sending traffic to MIT to 18.26.26.26 when traffic
to 192.192.192.192 might remain on the island.  Yes, it also
means some tunnelling overhead.
- --
| well, security is an issue with any of these schemes -- even
| serious ones :-). just because you have a kid-safe dns-name
| or ipv6 address or whatever, how does that force your
| web page to be truly kid safe? 

Think generally.

If you are caught then presumably you are in breach of contract
with whoever licenced you the address space or allowed you onto
the VPN - you get exposed to ridicule or worse sanctions.

This was my first message on the topic on the IETF list -- editorial
control is exercised by the people who configure the outbound tunnels.

If MIT-LCS thinks the Taiwan host is too cosy with the MIT-MEDIA
people, they just drop the tunnel, and 18.26.26.26 no longer works period.



<Prev in Thread] Current Thread [Next in Thread>