Subject: Re: Comments on draft-ietf-ipngwg-ipv6-anycast-analysis-01.txt

From: Erik Nordmark <[email-masked]>
Date: Sun, 16 Mar 2003 19:06:47 +0100 (CET)

> >RFC 3258 uses the term "shared-unicast address" for what you seem to be
> calling >"pseudo-anycast". I wonder if it makes sense using this existing
> term instead >of creating a new one.
> 
> 	if "shared-unicast address" is more common, i'm happy to use that term.

I don't know if that term is widely used, but I think it makes sense defining
it in the document and using it.

> 	i'll update the draft to refer RFC3258 and make necessary adjustments.
> 	i'm not sure if i should keep references to mohta-san's draft.

I think it's fine to keep the reference as long as you explain the salient
issues.

> 	i guess title of section 3 was vague - "current proposals" tries to mean
> 	"current proposals made for IPv6", like RFC2373 limitation for IPv6
> 	anycast address assignment.  therefore, 3.3 talks about restriction
> 	imposed by RFC2373, which is applicable to IPv6 only.
> 	i'll update title of section 3 to be more clear, and make sure to
> 	remove any IPv4 topic from section 3.

But RFC 2373 is more than a proposal - it is the IPv6 addressing architecture.
Even if some folks might want to change it I think it can be confusing to
calling it a proposal - the "current state of IPv6 anycast architecture"
might be more accurate since it indicates potential future changes without
treating it as merely a proposal.

> 	the paragraph tries to say:
> 	- if we use predefined site-local anycast address, the propagation of
> 	  host route (/128) would be limited within the site, therefore it may
> 	  be permissible (depending on the routing table size of the site)
or they might even be aggregated at an IGP area boundary...

> 	- if we use predefined global anycast address, host route needs to be
> 	  carried worldwide and we will see problems like you mentioned above.
> 
> 	how should i word it for clarity?

Point out in section 1 that anycast addresses have route scalaing issues.
If anycast addresses are drawn from the unicast address space (as is the case
in IPv6 and the IPv4 DNS anycast) the routing scaling impact can potentially
be limited by aggregating the anycast addresses as part of the regular unicast
routing prefixes. But this aggregation can only be applied when all members in
the anycast group remaing within the piece of toplogy whose routes get
aggregated. 
For instance having an anycast address where all the members belong to
one ISP means it the anycast address can be drawn from the ISPs address space
and be aggregated at the ISP boundary with no effect on route scaling outside
that domain. But having e.g. anycast groups with members across the whole 
Internet will have effect on the size of the routing tables  globally.

Does that capture what you want to say?

> >I don't see any text in section 4.1 in 2181 that recommends changing
> >anything on the client. In fact section 4 and 4.1 is how to make
> >servers work with clients that do verify the source address of the reply.
> >Thus I can't see how you come to this conclusion.
> 
> 	quoting RFC2181:
> >>   will be able to use it for further queries.  Servers configured in
> >>   such a way that not all their addresses are equally reachable from
> >>   all potential clients need take particular care when responding to	<---
> >>   queries sent to anycast, multicast, or similar, addresses.		<---
> 	from the above text, it is clear that client should/can not check the
> 	source address of the reply in the above case.

Your notion of clarity seems quite different than mine.
Section 4 in 2181 is about server behavior with recommendations on how to
make servers work with a large range of different client behavior.
But that doesn't mean that you can infer recommended or required client
behavior from that section.

> 	routers will know that the host is authorized to inject a route to
> 	the routing system, by the fact that it knows the shared secret
> 	used by the routing protocol (if the route is advertised with proper
> 	authentication encapsulation/extension header, it is authorized).
> 	do i need to be more clear on such trivial thing?  if so, how?

But if the host knows the shared secret used by the routing protocol it
can inject any route (e.g. default or some other prefix).
For anycast presumably one would want to restrict the host to only
inject a particular host route.

  Erik

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Tue, 18 Mar 2003 01:20:22 +0900

>treating it as merely a proposal.

	ok, will think about the section title.

>Does that capture what you want to say?

	yes.

>behavior from that section.

	then how can we make servers and clients interact?

>inject a particular host route.

	i don't think so.  you can say the same thing about routers -
	one would want certain router to be able to inject certain routes only,
	not the default route/whatever.  there's no such protocol available
	today. (s-bgp?)

itojun