> >>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"?
        and how is that different than "globally routable"?

        
> >        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.

        
> 
>    Brian

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

Reply via email to