Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios

[Fernando Gont <[e-mail]>]

On 20/2/19 23:28, j h woodyatt wrote:
> On Feb 20, 2019, at 17:13, Fernando Gont <[e-mail]
> <mailto:[e-mail]>> wrote:
>>
>> Given that RFC6092 recommends "only allow outgoing connections”...
> 
> I certainly don’t remember writing that, and I just double-checked the
> text, and I’m pretty sure that recommendation is not in RFC 6092. 

I quickly grep'ed RFC6092. Found this:

   If an inbound SYN packet is filtered, either because a corresponding
   state record does not exist or because of the filter's normal
   behavior, a filter has two basic choices: to discard the packet
   silently, or to signal an error to the sender.  Signaling an error
   through ICMPv6 messages allows the sender to detect that the SYN did
   not reach the intended destination.  Discarding the packet, on the
   other hand, allows applications to perform simultaneous-open more
   reliably.  A more detailed discussion of this issue can be found in
   [RFC5382], but the basic outcome of it is that filters need to wait
   on signaling errors until simultaneous-open will not be impaired.

   REC-34: By DEFAULT, a gateway MUST respond with an ICMPv6
   "Destination Unreachable" error code 1 (Communication with
   destination administratively prohibited) to any unsolicited inbound
   SYN packet after waiting at least 6 seconds without first forwarding
   the associated outbound SYN or SYN/ACK from the interior peer.

FWIW, I do agree with the advice.




> As far as I know, IETF has not yet actually written a Standards Track
> RFC that says Internet gateways SHOULD (note well: requirements
> language) block inbound flows to passive listeners. I’d be interested to
> know if I’ve missed that news. In any case, my recollection is that it
> wasn’t the case when RFC 6092 was published.
> 
> Shorter james: don’t blame me for this. I didn’t do it.

Actually, I'm in favor of such advice ;-)  I do think that CPEs should
support UPnP for IPv6, such that apps can punch holes in the fw, as they
do for the IPv4 case.


-- 
Fernando Gont
e-mail: [e-mail] || [e-mail]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1