more tunnels and what to do next

>
>>>>>> "Quaizar" == Quaizar Vohra <qv@cs.unh.edu> writes:
>
>    Quaizar> Hi Jim,
>    >>  What I think we need to do after configuring this with UNH on
>    >> the east coast.  Is determine a way of automating prefix
>    >> distribution on the 6bone with the tunnel end points.  You
>    >> should be able to directly send to UNH which is our leg of the
>    >> 6bone on the U.S. East coast. And not have to go through West
>    >> Coast given the prefix of the node based on RFC 1897.  We
>    >> should have the East Coast end point up soon.
>    >> 
>    >> If we could develop an algorithm to generate the IPv4-Tunnel
>    >> end point from the prefix which may be possible using RFC 1897
>    >> that would help a lot.
>    >> 
>    >> /jim
>    >> 
>
>    Quaizar> Looks like a good idea. How about everyone having 24 bit
>    Quaizar> IPv4 subnets. so that we have 64 bit prefixes formed from
>    Quaizar> there. Ex 132.177.118.0 is 84b1:7600 when I form a prefix
>    Quaizar> I get 5f02:3000:7600:84b1::/64. Then all can agree that
>    Quaizar> some standard last octet can be used to find the v4
>    Quaizar> address for the tunnel endpoint. How abot using the last
>    Quaizar> octet of your autonomous system # e.g. for us ASN is
>    Quaizar> 0x0230 so the last octet is 0x30 so the the tunnel
>    Quaizar> endpoint is 132.177.118.48.
>
>    Quaizar> This is pretty restrictive though, may be something on
>    Quaizar> similar lines.
>
>Sorry, but the idea seams terrible.
>
>This way to configure a tunnel you are requiring that end points have
>a particular IPv4 address which might be already in use by another
>system on your network, no matter what the scheme is. Also you impose
>that the is only one tunnel end-point per prefix. Some people already
>have more than one (for different tunnels of course), if i'm not
>mistaken, and i was planning on doing  the same.
>
>The second point is that i really don't understand what you're trying
>to achieve. If we're talking about static configuration here, then all
>you need to know is the other end prefix and v4 end-point. As you've
>seen the end-point info doesn't add too much space to the prefix list
>that you need anyway.
>
>And, as things are today, you can configure unidirectional
>links, i.e. configure a tunnel for which the other end point knows
>nothing, if you have the prefix and v4 address. Your proposal makes
>this even easier to happen, which i don't think is a good idea.
>
>If you ask the DNS, it will happily tell you quad-A records for my
>network but i would apreciate that people wouldn't start dumping
>packets to my tunnel end-point without prior agreement.
>
>The original question is if packets from A should go to B before
>reaching C, C being closer to A. I believe the answer to be: set a
>tunnel between A and C and tell B about it.
>
>regards,
>  Pedro.
>


I agree my idea is terrible.  

The question I think is to reduce the amount of static
configuration. Currently we can live with these, but not for long. But
wait for routing protocols till then.

But I would prefer using prefixes which would aggregate routes in one
region, i.e.  into shorter prefixes. So that people do heirarchial
routing and have less tunnels to configure. I agree that currenlty 6bone
is like mbone, but I hope we don't want it to continue like that for long.

For example here on East coast we can have one single tunnel end-point for
Digital, UNH and Bay and possibly others.

Quaizar

------------------------------------------------------
Quaizar Vohra
Inter-Operatibility Lab. (IOL), Univ. of New Hampshire
E-mail : qv@sun4.iol.unh.edu
Phone : (603)-862-0090



-- 
------------------------------------------------------
Quaizar Vohra
Inter-Operatibility Lab. (IOL), Univ. of New Hampshire
E-mail : qv@sun4.iol.unh.edu
Phone : (603)-862-0090