ietf
[Top] [All Lists]

Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> (Internet Protocol, Version 6 (IPv6) Specification) to Internet Standard

2017-02-13 11:51:56
On 13 Feb. 2017 11:40 am, "Brian E Carpenter" 
<brian(_dot_)e(_dot_)carpenter(_at_)gmail(_dot_)com>
wrote:

John,

On 13/02/2017 12:05, Leddy, John wrote:
I’m trying to understand how a ban of this functionality would work.  Is
it targeted at vendor products, precluding them from implementing the
functionality?

It's targetted at interoperability across the Internet. We can never stop
people doing whatever they please inside a private domain, obviously.
As always, there are no protocol police.

If there is a technical problem that can be solved by using EH insertion
within a domain where there are no harmful side effects, it should be able
to be used.
In a software networking world where functionality is being deployed that
is not from traditional network vendors; solutions that solve problems
efficiently will get deployed.

We had a lot of this conversation in a slightly different form prior to
RFC 6437. It proved impossible to specify "local domain" rules that could
reach consensus. I think we'd have the same problem trying to write rules
for header insertion/deletion within a domain. But in any case, that isn't
the target for RFC2460bis: the target is the Internet.


We also know that this statement from RFC1918 hasn't been 100% effective:



   Because private addresses have no global meaning, routing information
   about private networks shall not be propagated on inter-enterprise
   links, and packets with private source or destination addresses
   should not be forwarded across such links.


and we still don't have enough deployment of BCP38 which would also help
enforce that.

If it is possible to plug a device into the Internet I think it is better
to assume somebody probably will (and you won't be there to stop them) and
design to that assumption.

(All the recent "IoT" botnets and corresponding attacks are a result of
assuming those devices will only be connected to Private Internets, and
therefore they don't have to be individually "Internet proof" (conceptually
similar to a "water proof" watch).)

Regards,
Mark.



    Brian


John Leddy

From: ietf <ietf-bounces(_at_)ietf(_dot_)org> on behalf of "Eric Vyncke 
(evyncke)" <
evyncke(_at_)cisco(_dot_)com>
Date: Sunday, February 12, 2017 at 3:56 PM
To: Suresh Krishnan <suresh(_dot_)krishnan(_at_)gmail(_dot_)com>, 神明達哉 
<jinmei(_at_)wide(_dot_)ad(_dot_)jp>
Cc: "6man(_at_)ietf(_dot_)org" <6man(_at_)ietf(_dot_)org>, IETF Discussion 
list <ietf(_at_)ietf(_dot_)org>,
Pete Resnick <presnick(_at_)qti(_dot_)qualcomm(_dot_)com>, 
"draft-ietf-6man-rfc2460bis@
tools.ietf.org" <draft-ietf-6man-rfc2460bis(_at_)tools(_dot_)ietf(_dot_)org>, "
6man-chairs(_at_)ietf(_dot_)org" <6man-chairs(_at_)ietf(_dot_)org>
Subject: Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> (Internet
Protocol, Version 6 (IPv6) Specification) to Internet Standard

Suresh, Jinmei and Fernando,

I fully agree with you Suresh, the goal of an IETF last call is to get
NEW discussion and to re-do the lengthy discussions we had on 6MAN WG.

-éric

From: ipv6 <ipv6-bounces(_at_)ietf(_dot_)org> on behalf of Suresh Krishnan <
suresh(_dot_)krishnan(_at_)gmail(_dot_)com>
Date: Saturday 11 February 2017 at 07:11
To: 神明達哉 <jinmei(_at_)wide(_dot_)ad(_dot_)jp>
Cc: "6man(_at_)ietf(_dot_)org" <6man(_at_)ietf(_dot_)org>, IETF Discussion 
list <ietf(_at_)ietf(_dot_)org>,
Pete Resnick <presnick(_at_)qti(_dot_)qualcomm(_dot_)com>, Fernando Gont <
fgont(_at_)si6networks(_dot_)com>, 
"draft-ietf-6man-rfc2460bis(_at_)tools(_dot_)ietf(_dot_)org" <
draft-ietf-6man-rfc2460bis(_at_)tools(_dot_)ietf(_dot_)org>, 
"6man-chairs(_at_)ietf(_dot_)org" <
6man-chairs(_at_)ietf(_dot_)org>
Subject: Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> (Internet
Protocol, Version 6 (IPv6) Specification) to Internet Standard

Hi Jinmei,

On Feb 10, 2017 1:23 PM, "神明達哉" 
<jinmei(_at_)wide(_dot_)ad(_dot_)jp<mailto:jinm
ei(_at_)wide(_dot_)ad(_dot_)jp>> wrote:
At Thu, 9 Feb 2017 18:30:11 -0300,
Fernando Gont 
<fgont(_at_)si6networks(_dot_)com<mailto:fgont(_at_)si6networks(_dot_)com>> 
wrote:

While I largely agree with Fernando on everything he said, I have to
admit most of the points are just repeated from the 6man discussion,
and won't get us anywhere new by discussing these again at this point.
I guess the only new input for the IETF last call is this:

2) However, some folks came up with proposals to insert EH, on the basis
that "RFC2460 does not explicitly ban EH insertion". If there's people
arguing that, we clearly need to make this clear in the spec.

3) There was a consensus call, yes. When the call was made on the
mailing-list, the vast majority of supporters of "let's keep the
ambiguity" were folks from the same company as "2)". I have no idea if
this changes (or not) "consensus"... but this is clearly an important
datapoint.
Although I don't want to point a finger at particular people or
organizations without an evidence, I guess not a small number of 6man
participants (not only those who explicitly spoke up here) suspected
that the decision process was biased with the influence of a large and
powerful organization and the process and resulting "consensus" was
not really a fair one.  And I'm not an exception to it - in fact, it
was so unbelievable to me that we can't clarify an ambiguity even when
we were also open for future extensions, that I couldn't think of
other reasons than a company agenda.

Of course, it's quite possible that it was just a coincidence that
many people with the same organization genuinely thought we should
leave it ambiguous while many others strongly thought we should
clarify it but few (if not no) people from that organization supported
the clarification.  But I don't think we can prove it either way.

But as Fernando said, I believe this point (and that several, and
arguably more, participants suspected it) should be included in making
the decision at the IESG and at the IETF last call.  And, whatever the
decision, it would be more productive to move on after that and use
our time for some other things.

I am guessing that the people who spoke up during the WG process to not
put in an outright prohibition would make their case along with their
arguments here as well. We are only a week into a four week long last call.

Thanks
Suresh



--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6(_at_)ietf(_dot_)org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6(_at_)ietf(_dot_)org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
<Prev in Thread] Current Thread [Next in Thread>