Opened 11 years ago

Closed 8 years ago

#49 closed defect (fixed)

Multihoming confusion

Reported by: dthaler@… Owned by: draft-ietf-pcp-base@…
Priority: major Milestone:
Component: server-selection Version:
Severity: - Keywords:


Section 2.3:

The PCP machinery assumes a single-homed host model. That is, for a
given IP version, only one default route exists to reach the

I don’t think this is true. There’s no issue here with a host with multiple interfaces using the strong host model. And certainly no issue with a host with one IPv4 default route and one IPv6 default route on the same interface.

I think it assumes a single-homed *address* model. That is, for a given IP address, only one default route exists usable by packets sourced from that address.

Section 6.4:

As mentioned in Section 2.3, only single-homed CP routers are in
scope. Therefore, there is no viable scenario where a host located
behind a CP router is assigned with two Global Unicast Addresses
belonging to different global IPv6 prefixes.

No this doesn’t follow at al. Section 2.3 just mentioned one default route (which I continue to disagree with, but anyway). It said nothing about multiple prefixes or addresses. As long as there’s only one router, what’s the problem?

Section 7:

It takes the union of this
knowledge to decide to send a one or two MAP requests for each of its

Glad to see that multiple interfaces is indeed in scope.

Personally I believe that if you're behind a stateful NAT, then one PCP server will do (since it's the server with your external address and hence is guaranteed to be on-path). But if you're behind stateless boxes (e.g. firewall only, no NAT) then you probably want to talk to *all* PCP servers, since no single one is guaranteed to be on path.

Change History (8)

comment:1 Changed 11 years ago by dthaler@…

Section 6.1:

  1. the address of the default router is used as the PCP server.

Most hosts should have two… one for IPv4 and one for IPv6. (Some may have multiple for IPv6, or even IPv4 In my opinion it’s wrong to aply that such hosts simply cannot use PCP.) Suggest "2. the default router list is used as the list of PCP server(s)."

Then, regardless of whether the list was obtained from 1 (configuration like DHCP) or 2, I think the client has to filter the list down to those usable with the internal address in the request, unless there are none (in which case it needs to use the THIRD_PARTY option). Otherwise, you might end up picking an IPv6 server address to request an IPv4 mapping: the source IP won’t match the internal IP in the request, and if the server doesn’t support the THIRD_PARTY option, this will fail.

comment:2 Changed 11 years ago by dthaler@…

Stuart Cheshire writes:

  1. How to handle responses from multiple PCP servers is underspecified.

Responses don't arrive simultaneously. One arrives first, and then the other
arrives later. What should the client do when the later one arrives? Undo
everything it did in response to the first one?

comment:3 Changed 11 years ago by dthaler@…

7 June:
Alain - when we took out Zone id, we said we'd leave out multihoming from this spec (extensions ok).

Strawman: assume 1 PCP server per IP version and leave list to extension spec.
Fix text to pick PCP server by IP version.
Multiple interfaces text in section 7 moves to extension.
DHCP option spec also says client picks 1st one, but more is left to extension spec (to cover how to make multihoming work more generally, not DHCP specific)

comment:4 Changed 11 years ago by cheshire@…

  • Resolution set to fixed
  • Status changed from new to closed

Added text stating that all MAP mappings are EIM+EIF

comment:5 Changed 11 years ago by cheshire@…

Oops. Pasted in wrong comment. Comment for this change is:
Changed text to say that only one PCP server is currently supported

comment:6 Changed 11 years ago by cheshire@…

  • Resolution fixed deleted
  • Status changed from closed to reopened

We may still need more discussion of multihoming in general to close this ticket.

comment:7 Changed 8 years ago by dthaler@…

  • Component changed from base to server-selection

comment:8 Changed 8 years ago by dthaler@…

  • Resolution set to fixed
  • Status changed from reopened to closed

Addressed in -03.
Please open a new ticket for any feedback on -03.

Note: See TracTickets for help on using tickets.