status (Thursday soon)

[Francis Dupont]

> Draft 02 imposes a new ICMP message type (with type yet to be defined),
> and sends back a response that includes the port range that should be
> used.

=> this raises 2 issues:
 - there is only a little chance to get a new ICMP type
 - there is no real advantage over the standard ICMP followed by
  a reconfig

> Draft 01, on the other hand, just rejects with an ICMP type 13 message.

=> type 3 code 13 (aka unreachable administratively prohibited)

> So I believe the intersection could be, to send a message as in
> Draft-02, with the type set to 13.

=> no, you can't change the layout of an ICMP message. And it is
not required to put the new port range in the ICMP message.

> However, I'm now sure how the CPE is supposed to alter in real-time all
> of live NAT entries, to accommodate for the change. So I'm suspecting
> the sanest way to deal with this, is to configure the new port range
> within the SD-B4 and reboot the box :-(

=> this is the rude way, there is a less rude way: kill only the
connections using a no longer valid port. BTW we know how to implement
this: using the conntrack of Linux, and it should be joined to
the support of the PCP PEER opcode.

> Am I right with this analysis?

=> yes but in fact ICMP mechanisms have other defects:
 - they don't work with ICMP (no ICMP error triggered by an ICMP)
 - they don't work when the port range is augmented
 - they don't work when the mapped address is changed

Regards

Francis Dupont <fdupont at isc.org>