Re: [pcp] fwd: I-D Action: draft-ietf-pcp-anycast-03.txt

[Dave Thaler <[e-mail]>]

Sebastian Kiesel writes: 
> Section 2.1 (Client behavior) was reworded once again.  We decided to
> explicitly write down in which order the addresses should be tried, and not to
> simply reference RFC 6724 (as suggested in Honolulu); first because that RFC is
> a rather long document and we need only a tiny bit and second, because RFC
> 6724 is only for IPv6 and saying that the same rules should be applied
> analogously to IPv4 seems awkward.

That is absolutely not true.  RFC 6724 applies to IPv4 as well, as its abstract
clearly states.  RFC 6724, and RFC 3484 before it, have always applied to IPv4
and have been implemented and used as such for over a decade now.

>From the Honolulu minutes:
> Dave Thaler: server selection draft references RFC 6724.  Need to confirm
>    whether that spec would already prefer on-link router address over
>    an offlink anycast address.  If so, the ordering intended is still
>    preserved.

I just confirmed that the spec, and hence existing implementations of it,
would indeed already prefer an on-link router address over an offlink
anycast address. For IPv4, it would get down to per rule 9 of section 6,
which would have the intended effect; for IPv6, it would get it from 
rule 8.

Section 1 of draft -03 states:
> PCP clients usually send PCP requests to these addresses if
> no other PCP server addresses are known or after communication
> attempts to such other addresses have failed.

Citing 6724 would give that.

Section 2.1:
> 2.  for each supported address family, the PCP client creates an
>       ordered list, which contains the respective default router
>       address followed by the PCP anycast address (see Sections 4.1 and
>       4.2 for the IPv4 and IPv6 PCP anycast addresses, respectively).
>       These lists are used for requesting mappings for the respective
>       address family, following the rules for timeouts and
>       retransmissions in [I-D.ietf-pcp-server-selection].

The above text is broken in that it falsely assumes there's only one
default router (singular) per address family.  There isn't.  There 
can be multiple interfaces, and multiple default router addresses
per interface.  The text in RFC 6887 is much better in this respect
by using the term "the default router list (for IPv4 and IPv6)".
Second, it falsely implies that server-selection talks about a separate
list per address family.  It doesn't.  There's one list, where not all
addresses apply in all cases.  Again RFC 6887's text is much better.

Instead it should just say that the anycast addresses are to be
treated as additional addresses at the end of the default router list
mentioned in RFC 6887, and refer to server-selection.
No text is then needed to "replace" the text in RFC 6887, as
the text in RFC 6887 then becomes correct.

Section 1:
> it cannot provide timely information which CGN to interact with.

s/which/on which/

Section 4.1 (and similarly in 4.2):
> Typically used within a network operator's network domain, but in
> principle globally routable.

It wouldn't be globally routable in practice today because of prefix
length constraints in practice.   So either remove that phrase or
augment "in principle" with something like "(if a /32 route were
allowed in the default-free zone)".  My preference would be 
to simply remove that phrase since section 5.1 already says
"In the default-free zone, routers should be configured to drop such packets."

Section 5.1:	
Since IPsec could in principle be used to secure communication
with unicast PCP server addresses, it seems odd (though RFC 6887
is just as odd in that sense) to not mention whether IPsec
can work or not with the anycast server addresses and what the
operational problems with trying it would be.  I believe that
in theory it could work if the same keying material is used by
all PCP servers with the same anycast address, but if
there is a route change causing updates to go to a different PCP
server, then the negotiated IPsec session state would not be
present (I suspect IPsec would renegotiate and recover but
someone more familiar with IPsec details should say).
The other, perhaps bigger, operational problem is that the
anycast address is the same in every network, but the PCP
servers' keying information would be different in different
networks, and so it may or may not be possible (again, I 
would need an IPsec expert to say for sure) to configure clients
with per-network IPsec security info.   Of course, this
could all be avoided by using pcp-auth _instead of_ IPsec,
but the doc should at least say so.  (It does at least mention
pcp-auth which is good.)

-Dave