Bill, this is my last go on this. Not that I specially want
to leave you the last word, but if you don't get what I'm
saying after all this, it's pointless to continue. Below...

[EMAIL PROTECTED] wrote:
On Wed, Dec 08, 2004 at 11:33:28AM +0100, Brian E Carpenter wrote:

[EMAIL PROTECTED] wrote:

Bill, you could do that if the prefixes are *routed* but that is
not going to be the case if the ULA spec is followed, except for
private routing arrangements. Since the spec says they MUST NOT
be globally routed, it seems entirely rational to apply the same
rule to your zone files. But as I said before, I can live with
SHOULD NOT.

Brian


please define "globally routable" in technical terms.

Why? I didn't use that phrase. The draft doesn't say that, it says that ULA prefixes must not be globally routed. Different.


i guess that i am confused here. what does it mean to be "globally routed"?

Advertised in BGP4+ between all or most ISPs.


to borrow your term, thats pretty woolly as well.
ISP is very nebulous. It has never been adaquately
defined. given that the predominant EGP (BGPv4) has extensive
knobs for policy control, there is not and can not be a common view of "globally routed". One can take snap shots from various "peepholes" but that does not global routed make.
What really matters is can i get my packets to the folks who want/need then and can they get their packets to me? There is no such
thing as a "globally routed" prefix. They do not exist.
I would like to be proven wrong of course, but I don't think
it can be done. Please prove me wrong.

It is certainly true (and I check potaroo.net regularly) that the default-free zone is different according to where you sit in the network. But it's equally true (and the recent pseudoPI proposal confirms it) that having any particular view of the DFZ polluted by a few thousand non-aggregated long prefixes (for any definition of "long" that you prefer) doesn't actually matter. That's the beauty of BGP4, in fact. So, while you are correct that there is no unique definition of "globally routed", because there is no globally unique DFZ, I don't think this affects the logic here at all. If a prefix is advertised in one or more of the world's DFZ's, it's in practice globally routed.



and how is that different than "globally routable"?

I didn't attempt to define that since it is indeed a woolly phrase. Any prefix *could* be globally routed; the interesting question is whether it *is* globally routed.


        bingo!  and since globally routed is nebulous, it does nto
        matter... what matters is, do my packets get to where they are going
        and will the desired replies get back.

Well indeed. I wasn't trying to say anything else.



    and since routing is not the same as lookup, your assertion
    about the "rational" nature of registration in a lookup system
    does not hold much credence.

Not at all. As others have pointed out, if DNS returns AAA records for prefixes that are not in fact routed, TCP timeouts will result. That's sufficient reason to not put such records in your zone files.


so your DNS server in Zurich is expected to have knowledge about the state of the routing system between ISPs in Argentina?
This problem is functionally identical to the original route server
concept that was used in the NSF NAPs. ISP A could talk to the RS and ISP B could talk to the RS, but they could not talk to each
other ... From the RS point of view, it had no knowledge of the
policy filters that prevented these two ISPs from exchanging traffic.


DNS is a lookup system. It has zero idea about the currnet state
of reachability/routedness ... telling me i should not place records
in my DNS that are useful to me, just because they are not useful to you is presumptious at best.


        when/if the DNS carries explicit routing information, then i'll be
        willing to buy into your argument... not until then though.

Perhaps you don't like the reality that most enterprises operate 2-faced DNS, but they do.


what does that have to do with this question?

Let's assume that server.example.com has an AAAA record that returns a ULA inside company example.com, but the AAAA record is not exported from example.com. (That's common practice today with A records that return RFC 1918 or even global IPv4 addresses that don't happen to be routed by example.com's ISP. In fact, that's what will happen when I press Send on this email.) I think all the ULA draft can say is that this should be normal practice - don't put an AAAA record outside your firewall if the underlying address isn't routed outside your firewall. And it isn't in fact anything specific to ULAs.

    Brian

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to