Re: [v6ops] draft-ietf-v6ops-6to4-advisory WGLC

[Pekka Savola <[e-mail]>]

On Thu, 21 Apr 2011, Brian E Carpenter wrote:
>> Section 2.1 on Router 6to4 should be trimmed down, one page is
>> excessive.  6to4 was never deployed as it was initially devised by
>> Carpenter, so text on that is not very useful (most of 1st paragraph of
>> Section 3 should also go away).  The key point is that 6to4 hosts or
>> routers may either configure the relay router IP address or use anycast.
>
> You made this comment on an earlier version. I disagreed then and I disagree
> now. It's impossible to understand how the anycast version is supposed to
> work unless you understand how basic 6to4 is supposed to work, and the
> situation for the return relay is the same in both cases. I couldn't find
> anything redundant in the explanation.

You seem to be arguing that S 2.1 is an overview of 6to4 without 
anycast and that such an overview is essential.

I'd argue that this document does not need to provide a description of 
how basic 6to4 or anycast 6to4 works; it is already described in those 
documents, and it is not essential in order to understand the rest of 
the document. The reader can get the message of the document even if 
(s)he isn't very familiar with rfc3056 or rfc3068 even without the 
details in Section 2.


>> .. it was not described if the return path relay used 192.88.99.1 as the
>> source address of packets or the non-anycast address.  I would expect
>> significantly more breakage when 192.88.99.1 is NOT used as the source
>> address.  Firewalls in residential case are rarely an issue based on my
>> experience if the relay uses 192.88.99.1 as the source address.
>
> It is mentioned somwhere that there is conflicting evidence on this
> point - actually it depends on whether the client is behind a stateful
> firewall or not. So I think this point is covered.

There are two different axes here - firewall and source address:

1. stateful firewall
2. stateless firewall

a. relay uses 192.88.99.1 as source
b. relay uses non-anycast as source

I'm saying that 1.b) cannot work and this is likely causing bad 
figures in Geoff's study.  1.a) can work out of the box with zero 
configuration. Therefore the point is not (only) "stateful firewall" 
but also (or mainly) source aaddress.  Both 2.a) and 2.b) are likely 
to work with roughly the same probability.

There are actually more granularity in how firewalls work, but that 
shows that using 192.88.99.1 as source is _especially important_ for 
stateful firewalls.

>>    5.  PMTUD Failure: ...Path MTU Discovery does not
>>        always work, and this can lead to connectivity failures.  Even if
>>        a TCP SYN/ACK exchange works, TCP packets with full size payloads
>>        may simply be lost.
>>
>> .. due to MSS negotiation this is not a problem if 6to4 is set up on a
>> host because it will set MSS lower than 1500-40=1460B.
>
> I have personally experienced MSS negotiation failing in exactly this
> case. Probably that is an implementation bug at the server side, and I
> agree this point should be mentioned.

I'd actually suspect that the issue is more at the client side, i.e., 
the client doesn't lower MSS based on where the default route points.

>> Section 4.1 is out of place here.  Remove or broaden the scope of the
>> document to include vendors.
>
> That's why the first sentence of this section says
> "  Although this document is aimed principally at operators, there are
>   some steps that implementers and vendors of 6to4 should take."

I read that.  But it isn't written in the abstract or introduction. 
IMHO, either this needs to be made a first-class citizen in the 
document or it should be removed.

>> S 4.2:
>>    Unless the answer to all these questions is 'yes', subscribers will
>>    be no worse off, and possibly better off, if the route to 192.88.99.1
>>    is blocked and generates an IPv4 'destination unreachable'.  There is
>>    little operational experience with this, however.
>>
>> .. this must be removed unless there is more operational experience with
>> this approach.  Hinting at the ISPs that this could be a good approach
>> is very wrong if we don't know that it is actually the case.
>
> I don't see that. We know that it cannot make things worse and might
> make things better.

Disagree.

If the concerned ISP is able to ping 192.88.99.1 and the relay will 
forward traffic from the concerned ISP's IP addresses, it is "better 
than nothing".  It is a working 3rd party service that the concerned 
ISP is disrupting.  In some countries this can even be illegal unless 
a provision is made in the contract to allow such blocking.

I agree only with the part that if:
  a) 192.88.99.1 address does not respond,
  b) does not provide 6to4 service that works, or
  c) the isp customers are all using bogonized addresses [you could 
think this as a special case of b)]

.. then it is known that, at least at that particular moment, the 
concerned ISP is no worse off by returning ICMP unreachables.

>> editorial:
>>
>> - references to labs.ripe.net, www.potaroo.net etc. should be filed as
>> informative references not direct URLs in text.
>
> We can leave the RFC Editor to apply their preferred policy for this.

I think you very well know that this is not RFC editor's preferred 
policy.

I feel it is irresponsible to push out text (also to the IETF LC and 
IESG) that has known editorial irregularities.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings