in response to this prompt: Paul Vixie <[EMAIL PROTECTED]> wrote: > > if we're going to expect routability to provide connectivity in some cases > > but not all, which is what's implied by saying "never appear off-site", > > then we need to know what cases and exactly what noncases. so what's a > > "site"? or what's an "administrative domain"? or call it what you want > > -- what is it and how do the routing domain, connectivity domain, and the > > allocation domain relate to each other?
so far, there've been two answers, coincidentally both from boeing.com. "Templin, Fred L" <[EMAIL PROTECTED]> wrote: > My understanding is that when two sites agree to form a peering arrangement > and are joined, e.g., by a VPN link, then they should be able to advertise > their ULA-C's for use within the scope of their now-linked sites. So, it's > not about a site freely redistributing its ULA routes into any other > arbitrary site; there should be an explicit peering arrangement first. i understand about peering and i would like to agree but i don't. perhaps i know too much about peering. when networks A and B are peers, and network C is a customer of network B, then A and C will use B for "transit". there is no reasonable expectation that ULA-C could be, would be, or should be exempt from that treatment. furthermore, if C is B's customer for DFZ reachability, then C will be able to reach A's ULA-C routes through B's default route, and will not be able to tell the difference between distant ULA networks and distant non-ULA networks. this is one of the reasons i consider the thus-far definitions of "site" to be so useless: "does not encounter reality well." "Manfredi, Albert E" <[EMAIL PROTECTED]> wrote: > I think the answers to these questions are exactly the same as they would be > for IPv4 private address blocks, although it's more imperative in the case > of IPv4 that they be non-routable outside whatever boundaries one sets. So > then ... "more imperative" is a hard tool to operate. who shouldn't route these, why, and how will we stop them, and what bad things happen if we can't stop them? > > if i seem anxious to cut to the chase it's because i've read all this > > before when "site local" was first proposed and then later, again, when it > > was deprecated. so let's keep our feet on the ground and define our terms > > and make sure we have common understanding before anybody runs out ahead. > > Does anyone have an answer to this? Site local were deprecated because > the consensus was that there's no need for "private" addresses in IPv6. site-local was deprecated because nobody could agree what a "site" was, which in other words means it's down under the same swamp we are now waist deep in. > Are these ULA-Cs simply taking their place? > > Should routers not forward ULAs under any circumstance? that would be a fine, clean design. perhaps if it were a hard requirement, then the "IPv6 Ready" folks would deny the use of the logo to anyone who leaked packets or routes in this address space, or who provided any kind of command level override. make it "nonrouteable" even among two LANs run by the same sysadmin. if you want those LANs to talk, then bridge 'em, don't route 'em. (but in that case we'd be using link-local, right?) (what'll we do if some open source geeks publish free software without a logo on it?) (and if we don't think these addresses or routes to them could leak, then why are we asking that they be unique?) so my previous question stands. what's a "site"? -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
