Liubing (Leo | 13 Feb 06:22 2016

FW: New Version Notification for draft-ietf-v6ops-dhcpv6-slaac-problem-06.txt

Hi Dear all,

This is a new version of the draft. We made not a few revision to improve the readability, but there's no
essential technical change.
Comments are appreciated.

Best regards,
Bing


-----邮件原件-----
发件人: internet-drafts <at> ietf.org [mailto:internet-drafts <at> ietf.org] 
发送时间: 2016年2月6日 17:13
收件人: Liubing (Leo); Sheng Jiang; Xiangyang Gong; Wendong Wang; Enno Rey
主题: New Version Notification for draft-ietf-v6ops-dhcpv6-slaac-problem-06.txt


A new version of I-D, draft-ietf-v6ops-dhcpv6-slaac-problem-06.txt
has been successfully submitted by Bing Liu and posted to the IETF repository.

Name:		draft-ietf-v6ops-dhcpv6-slaac-problem
Revision:	06
Title:		DHCPv6/SLAAC Interaction Problems on Address and DNS Configuration
Document date:	2016-02-05
Group:		v6ops
Pages:		23
URL:            https://www.ietf.org/internet-drafts/draft-ietf-v6ops-dhcpv6-slaac-problem-06.txt

Status:         https://datatracker.ietf.org/doc/draft-ietf-v6ops-dhcpv6-slaac-problem/

Htmlized:       https://tools.ietf.org/html/draft-ietf-v6ops-dhcpv6-slaac-problem-06

Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-dhcpv6-slaac-problem-06

(Continue reading)

internet | 12 Feb 18:19 2016
Picon

I-D Action: draft-ietf-v6ops-host-addr-availability-05.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Operations of the IETF.

        Title           : Host address availability recommendations
        Authors         : Lorenzo Colitti
                          Vint Cerf
                          Stuart Cheshire
                          David Schinazi
	Filename        : draft-ietf-v6ops-host-addr-availability-05.txt
	Pages           : 14
	Date            : 2016-02-12

Abstract:
   This document recommends that networks provide general-purpose end
   hosts with multiple global IPv6 addresses when they attach, and
   describes the benefits of and the options for doing so.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-host-addr-availability/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-v6ops-host-addr-availability-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-host-addr-availability-05

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

(Continue reading)

Tim Chown | 12 Feb 07:59 2016
Picon

Re: Review of draft-ietf-v6ops-ula-usage-considerations

On 12 Feb 2016, at 00:15, Brian E Carpenter
<brian.e.carpenter@...> wrote:
> 
>> On 12/02/2016 06:27, Dale W. Carder wrote:
>> Thus spake Brian E Carpenter (brian.e.carpenter@...) on
Thu, Feb 11, 2016 at 01:33:31PM +1300:
>>>> On 11/02/2016 09:34, Dale W. Carder wrote:
>>>> Thus spake Fernando Gont (fgont@...) on Wed, Feb 10, 2016 at
01:21:50PM -0300:
>>>>> 
>>>>> * Section 3.2: Do folks really generate the prefixes as "required"?
>>>>> Me, I confess I've used things like fc00:1::/64 because they are simpler
>>>>> that some random string of bits.
>>>> 
>>>> I absolutely do not believe it can be expected that sites will generate 
>>>> random prefixes.
>>> 
>>> Why not, if it's a built-in feature of the CPE? Obviously, humans shouldn't
>>> be messing around with these things.
>> 
>> Oh, I should clarify my concerns are not at the CPE level, but at the 
>> enterprise scale where ULA may be used with human friendly / poorly chosen 
>> prefixes that inevitably overlap.
> 
> If ULAs are assigned other than as defined in the standard, sure. But that
> is just as bad a blunder as stealing a routable prefix and I would have
> little sympathy.
> 
> The chance of a clash when two networks merge is minute if you apply the standard.
> 
(Continue reading)

Tim Chown | 11 Feb 17:34 2016
Picon

Re: Review of draft-ietf-v6ops-ula-usage-considerations

> On 11 Feb 2016, at 00:33, Brian E Carpenter <brian.e.carpenter <at> gmail.com> wrote:
> 
> On 11/02/2016 09:34, Dale W. Carder wrote:
>> Thus spake Fernando Gont (fgont <at> si6networks.com) on Wed, Feb 10, 2016 at 01:21:50PM -0300:
>>> 
>>> * Section 3.2: Do folks really generate the prefixes as "required"?
>>> Me, I confess I've used things like fc00:1::/64 because they are simpler
>>> that some random string of bits.
>> 
>> I absolutely do not believe it can be expected that sites will generate 
>> random prefixes.
> 
> Why not, if it's a built-in feature of the CPE? Obviously, humans shouldn't
> be messing around with these things.

Sure, for a home network maybe. But in a campus you’d probably form an address plan
for your global prefix and map that to ULA space, e.g. 2001:db8:123:456::/64 would have
a corresponding ULA prefix of fc00::123:456::/64.

Not that I’m aware of any campuses yet using ULAs. 

>> This will result in more NAT
> 
> No. ULA is for internal traffic only. You use your ISP-provided prefix for
> the Internet.

Indeed. In theory.

>> and all of the horror
>> stories from rfc1918 getting copied over.  For a while someone (SixXS?)
(Continue reading)

Fernando Gont | 10 Feb 17:21 2016

Review of draft-ietf-v6ops-ula-usage-considerations

Folks,

I did a fresh review of the aforementioned I-D. I didn't follow previous
discussions of this topic, so my apologies if I raise something that has
already been discussed to death, etc.

** Technical **

* Meta: Both section 4 and section 6 contain use cases. This is rather
confusing. e.g., not sure what's the criteria to ut some of the use
cases in Section 4, while others in Section 6. Unless I'm missing
something, this should be fixed.

* Section 3.2: Do folks really generate the prefixes as "required"?
Me, I confess I've used things like fc00:1::/64 because they are simpler
that some random string of bits.

* Section 3.4, page 4:
> Externally-destined data can be sent to the Internet or
> telecommunication network by a separate function, through an
> appropriate gateway/firewall.

Please remove "firewall". A firewall wouldn't really help with that.

* Section 4.1, page 4:
> IP is used ubiquitously.  Some networks like industrial control bus 
> (e.g.  [RS-485], [SCADA], or even non-networked digital interfaces 
> like [MIL-STD-1397] have begun to use IP.  In these kinds of 
> networks, the system may lack the ability to communicate with the 
> public networks.
(Continue reading)

otroan | 10 Feb 17:01 2016

Re: IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt)

Fernando,

>>> If it's an implementation limit, it'd be great that we all agree that
>>> 40B is the least common denominator.
>> 
>> IPv6 has had that limit for 20 years.
> 
> Sorry, I missed your point. So essentially you're agreeing that Ehs do
> not work. IN which scenarios should one implement something as an EH,
> since we cannot rely on them?

how did you manage to reach that conclusion?
I'm saying there are very few use cases (ECMP and DDOS) requiring parsing further than the IPv6 header in
transit networks.
with the caveats mentioned previously I believe EHs work as well as they can be made to work.

apart from:
 - encourage the deployment of flow-label
 - "fixing" the HBH header
 - strongly discourage new EHs

I think the IETF has done (more than) enough on this topic for a while.

cheers,
Ole
_______________________________________________
v6ops mailing list
v6ops@...
(Continue reading)

otroan | 10 Feb 13:21 2016

Re: IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt)

Fernando,

>>> Not necessarily. There are essentially two issues here:
>>> 
>>> 1) The Next-Header space is not self describing. It should be
>>> possible to skip past unknown EHs. I presented a proposal
>>> (draft-gont-6man-rfc6564bis-01), but we did nothing about it.
>>> (there could be other alternatives, such as prohibiting the
>>> specification of new EHs... but we did nothing about it).
>> 
>> right, it isn't clear that is solving the problem. if walking the
>> chain is done by a middlebox for the purpose of "security", then it
>> would be highly unlikely that it would allow an unknown extension
>> header.
> 
> That's the point: you cannot tell if what's inside is an EH or an
> upper-layer protocol.
> 
> If the device is whitelisting stuff, I'd agree with you on the
> end-result. OTOH, if the devices means to blacklist stuff, then this may
> lead to unnecessarily packet drops.
> 
> And, in any case, a bug is a bug.
> 
> We're pretending that RFC6564 can be employed to skip past unknown EHs,
> when it really can't.

no, we're not. we're saying that skipping past unknown headers is not useful/possible in the general case.

>> for a router doing ECMP we should instead make the flow label
(Continue reading)

Philip Homburg | 10 Feb 13:18 2016

Re: IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt)

In your letter dated Wed, 10 Feb 2016 08:47:13 -0300 you wrote:
>Agreed. What I'm saying is that in scenarios in which you just want to
>drop stuff that is known to be evil, but otherwise pass everything else,
>you'd need to be able to jump past unknown EHs, and you currently cannot
>do that. And I think you should be able to.
>
>That aside, we currently assume that it is possible to jump past unknown
>EHs when it's not really possible. That's a current bug in our specs.

I think it would be perfectly fine if a vendor supports unknown 
extension headers only if they conform to RFC 6564, which is standards
track.

So the only thing is that operators would have to explictly mark protocol
values as RFC-6564 compatible extension headers that are safe to ignore.

The 'safe to ignore' part has to be manual anyhow.

>What concerns me is that we pretend that there is stuff (EHs) that is
>deployable, when it currently isn't.
>
>So we better try to do something to get some subset of that deployable
>(and it becomes clear that you can only rely on such subset to work) and
>we declare some sort of humble victory :-), or we forget about it and
>assume defeat.
>
>What worries me is when there is a disconnect between the specs and the
>real world: a folk that reads the spec assumes that something will work,
>but he misses the unwritten wisdom that says that part of what we read
>actually fails badly.
(Continue reading)

Alexandre Petrescu | 10 Feb 13:18 2016
Picon

distributed gaming on IPv6 - any platform?

Hello,

Is there any distributed gaming platform that runs on IPv6 too?

A colleague informs me that the opensource GamingAnywhere does not support IPv6.

But IP is very important between the gamepad and the box.  The use of IPv4/USB between a pad and a box (rather than USB) allows several enhancements like energy efficiency, smartphone-as-gamepad, etc.

If IPv6 is considered between the pad and the box, it can become a significant use-case for technologies like 64share, DHCPv6-PD, and in general the need for multiple IPv6 addresses per device.

Is there any distributed gaming platform that runs on IPv6 too?

Alex

_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops
Philip Homburg | 10 Feb 12:29 2016

Re: IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt)

In your letter dated Wed, 10 Feb 2016 07:21:59 -0300 you wrote:
>That's the point: you cannot tell if what's inside is an EH or an
>upper-layer protocol.
>
>If the device is whitelisting stuff, I'd agree with you on the
>end-result. OTOH, if the devices means to blacklist stuff, then this may
>lead to unnecessarily packet drops.
>
>And, in any case, a bug is a bug.

Call me paranoid, but I'm quite happy if a security device drops stuff it
doesn't understand.

It shouldn't be that hard to support a white list of unknown extension
headers that can be set by the operator. 

>But when we don't try to be pragmatic and agree on what is supported,
>the result is not good: I'd prefer to be "limited" in the EH chains that
>I can use, but to know that I can rely on e.g. up to 64B or 256B EH-chains.
>
>Right know, since our requirement to support arbitrarily-long EHs is
>generally seen as too onerous, the end result is that folks don't care
>to support EHs, and hence you wouldn't even hope to have your 10B EH
>chains go through the network.

It is always possible to find an excuse for not doing something.

There is a very common pattern of a fragmentation header in front of a UDP
header, which just needs to be supported on todays internet. 

Beyond that, I haven't seen a strong desire for extension headers expressed
outside IETF mailing lists. So there the use cases seem quite remote 
compared to all other new features that need to be supported.

_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops

otroan | 10 Feb 10:52 2016

Re: IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt)

Fernando,

>> my point was that it was absurd to try to design network protocols in
>> a way that they would accommodate any possible policy decision made
>> in the network or by end-hosts. it isn't the IETFs job to try to
>> bypass whatever policy a network choses to implement.
> 
> My take here is that some design decisions make it hard for networks to
> enforce the policies they choos to enforce.
> 
> e.g., I recall you quoting S. Deering suggesting that the EH structure
> was meant to make the life of middleboxes painful. I regard that as a
> rather bad design decision (put another way: would you have EH chains
> the way we have them n IPv6 if you were to redesign IPv6?).
> 
> 
> 
>> if we accept that e.g. a transit network needs to look into L4 or
>> deeper, then we also accept we can never make any innovations at this
>> layer. (and we've essentially accepted that the Internet is going to
>> be just an underlay for whatever comes next).
> 
> Not necessarily. There are essentially two issues here:
> 
> 1) The Next-Header space is not self describing. It should be possible
> to skip past unknown EHs. I presented a proposal
> (draft-gont-6man-rfc6564bis-01), but we did nothing about it. (there
> could be other alternatives, such as prohibiting the specification of
> new EHs... but we did nothing about it).

right, it isn't clear that is solving the problem.
if walking the chain is done by a middlebox for the purpose of "security", then it would be highly unlikely
that it would allow an unknown extension header.

for a router doing ECMP we should instead make the flow label usable.

what we have done, is to make it very unlikely that new extension headers will be defined. given that we have
the three extensible containers, RH, DestOpt and HBH. and we might be making parsing the HBH optional.

> 2) EH chains can be very long. Me, I'd prefer that we get to some
> compromise (e.g., "everyone must support EH chains of at least 256 bytes
> to be able to claim they are IPv6-ready"), rather than what we have now:
> we pretend that nodes support the currently unlimited EH chain lengths,
> but in practice it gets hard to pass a 10B chain through.

right, but within the constraints of RFC7112.
for routers that number is and always have been 40. :)
for middleboxes it is dependent on policy, and since that could typically be to parse the whole packet...

>> I can't think of many examples where a transit network would require
>> to parse the extension chain.
> 
> We have examples in draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt
> (supplied by folks running such networks).

sorry, I don't see any examples there where a transit network would require to look deeper than 40 bytes.
in the case of DDOS that would be filters that would match a signature, and I'd imagine that include
extension headers right.
>> in the case of ECMP, we are better off
>> with IPv6 than IPv4, although we have to do something to get
>> flow-label based ECMP deployed / implemented.
> 
> Agreed.
> 
> 
> 
>> but even today you can do reasonably well without parsing EHs:
>> 
>> if (flow_label > 0) { flow_hash = f4(sa,da,protocol, flow) } else {
>> if (nh == UDP|TCP) { flow_hash = f5(sa,da,protocol,sport,dport) } //
>> Do something with GRE keys } else { flow_hash f3(sa,da,protocol) }
>> adj_index = flow_hash & (nadj - 1)
> 
> Probably the ECMP case is easier to solve in the near term. OTOH, the
> ability to do packet filtering doesn't look easy to solve if we keep the
> (rather onerous nowadays) requirement of supporting arbitrarily-long EH
> chains.
> 
> FWIW, this is just me trying to make things work, and trying to find a
> middle-ground between the theoretical requirements we expect
> implementations to comply with, and the "I will drop all the EH-enabled
> packets" that seems to be rather widespread.

right, this is simply a result of the tussle between the different actors on the network.
if anything IETF should try to be neutral in that tussle.

cheers,
Ole
_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops

Gmane