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

From: Sebastian Kiesel <[email-masked]>
Date: Mon, 22 Dec 2014 18:01:07 +0100

Dear all,

this is the post-WGLC/post-Honolulu version of the PCP anycast draft.
Many thanks to all reviewers!

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.

Further significant changes:

- Add "Updates: 6887 (if approved)" to front page
- Use case in Introduction section
- Expanded Deployment Considerations and Security Considerations
  sections, as discussed in WGLC and Honolulu

Thanks
Sebastian

----- Forwarded message from [email-masked] -----

Date: Mon, 22 Dec 2014 08:58:31 -0800
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: [pcp] I-D Action: draft-ietf-pcp-anycast-03.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Port Control Protocol Working Group of the IETF.

        Title           : Port Control Protocol (PCP) Anycast Addresses
        Authors         : Sebastian Kiesel
                          Reinaldo Penno
                          Stuart Cheshire
	Filename        : draft-ietf-pcp-anycast-03.txt
	Pages           : 12
	Date            : 2014-12-22

Abstract:
   The Port Control Protocol (PCP) Anycast Addresses enable PCP clients
   to transmit signaling messages to their closest on-path NAT,
   Firewall, or other middlebox, without having to learn the IP address
   of that middlebox via some external channel.  This document
   establishes one well-known IPv4 address and one well-known IPv6
   address to be used as PCP Anycast Addresses.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-pcp-anycast/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-pcp-anycast-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-pcp-anycast-03

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
pcp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcp

----- End forwarded message -----

---

From: Dave Thaler <[email-masked]>
Date: Mon, 22 Dec 2014 21:00:59 +0000

Sebastian Kiesel writes: 
> 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

---

From: Sebastian Kiesel <[email-masked]>
Date: Tue, 23 Dec 2014 01:08:02 +0100

> and have been implemented and used as such for over a decade now.

point taken, if I read it again after reading RFC 6540 first.

[...]
> the text in RFC 6887 then becomes correct.

2.1.  PCP Discovery Client behavior

   The PCP anycast addresses (see Sections 4.1 and 4.2) are added after
   the default router list (for IPv4 and IPv6) to the list of PCP
   server(s) (see Section 8.1 of [RFC6887]).  This list is processed as
   specified in [I-D.ietf-pcp-server-selection].

   Note: If, in some specific scenario, it was desirable to use only the
   anycast address (and not the default router), this could be achieved
   by putting the anycast address into the configuration file, or DHCP
   option, etc.

2.2. ...

OK?  

I am not a native speaker. Please help with grammar if neccessary.

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

fixed.

> length constraints in practice.

True. But I don't think we have a problem here.  RFC 5736 says:

   The IANA registry notes, as a general comment, that address prefixes
   listed in the IPv4 Special Purpose Address Registry are not
   guaranteed routability in any particular local or global context.

> So either remove that phrase or
> allowed in the default-free zone)". 

In the context of Question 7 of RFC 5736, is "globally routable"
equivalent to "there is a route in the default-free zone"?

> My preference would be 

We need to answer Question 7 of RFC 5736 with routable only in scoped,
local, or private contexts, or globally.

The current approach is to say "globally" but relativize it. Are we sure
that we really want to restrict ourselves to one of the other options
(and can we define exactly what the appropriate scope is)?

> but the doc should at least say so.  (It does at least mention

These problems are not specific to the PCP use case of IP anycast.
I don't think we should try to find exhaustive answers within the
context of this document.

Thanks
Sebastian