fred | 29 Oct 17:10 2014
Picon

new draft: draft-chen-v6ops-nfv-ipv6

A new draft has been posted, at http://tools.ietf.org/html/draft-chen-v6ops-nfv-ipv6. Please take a
look at it and comment.

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

fred | 29 Oct 16:14 2014
Picon

new draft: draft-vyncke-v6ops-happy-eyeballs-cookie

A new draft has been posted, at
http://tools.ietf.org/html/draft-vyncke-v6ops-happy-eyeballs-cookie. Please take a look at it
and comment.

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

fred | 29 Oct 16:08 2014
Picon

new draft: draft-vyncke-v6ops-happy-eyeballs-cookie

A new draft has been posted, at
http://tools.ietf.org/html/draft-vyncke-v6ops-happy-eyeballs-cookie. Please take a look at it
and comment.

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

Tim Chown | 28 Oct 21:14 2014
Picon

Re: I-D Action: draft-vyncke-v6ops-happy-eyeballs-cookie-00.txt

On 28 Oct 2014, at 14:46, Simon Perreault <sperreault-2XzuAfyEbGY@public.gmane.org> wrote:


On Tue, Oct 28, 2014 at 10:29 AM, Fred Baker (fred) <fred-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org> wrote:
I would be interested in folks’ view of this. Is this interesting?

Kind of.

There are a lot of web apps that tie session cookies to IP addresses. In my day-to-day life the top offender is Bugzilla. You can still see the infamous checkbox here:


"[X] Restrict this session to this IP address (using this option improves security)" (emphasis mine)

Many open source projects use Bugzilla. If this draft's only accomplishment is making this checkbox disappear, then IMHO it will have been a huge success. ;)

One improvement to the draft could be to justify why what it suggests (i.e., not tying sessions to IP addresses) does not lower security. You have to convince technical people to remove a feature that was up to now advertised as "improving security". This can be a hard sell.

This would be a good outcome of this draft.

There can be not dissimilar issues between visits to the same site when the OS picks a different IP version per visit (as OSX is prone to do).

Tim

_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops
fred | 26 Oct 19:00 2014
Picon

draft-ietf-v6ops-dhcpv6-slaac-problem WGLC

The working group last call for this draft announced last week
continues for another week.  Please feel free to comment on it.

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

Gert Doering | 23 Oct 10:41 2014
Picon

Re: [GROW] Deaggregation by large organizations

Hi,

On Thu, Oct 16, 2014 at 06:18:34PM -0700, Matthew Petach wrote:
> The probability of us figuring out how to scale
> the routing table to handle 40 billion prefixes
> is orders of magnitude more likely than solving
> the headaches associated with dynamic host
> renumbering.  That ship has done gone and
> sailed, hit the proverbial iceberg, and is gathering
> barnacles at the bottom of the ocean.

What I find scary in this statement is the underlying "one solution must
fit all users" mentality.

I can fully see and understand Owen's point that in an *enterprise*
environment, renumbering is truly hard, because you need to get lots of
other people that have no real interest to renumber stuff in their config
files - and yes, vendors of <whatever> that could handle DNS lookups and
combinations of "get prefix from DNS, attach <localbit>, put result into
usage" would be truly nice, but indeed, that should have been specced
15 years ago to be available now (maybe).

OTOH, there's the large mass of SOHO style users, where "dynamic host
renumbering" *really* is a non-issue.  I've gone there and tested it
in a homenet testbed with two IPv6 uplinks, so multi-homing and 
src-based routing thrown in - it works.  It needs polishing and some
IETF work here and there (SAS failover comes to mind, and labels-to-
prefixes) but it works better than "IPv4 with two providers" today,
for that particular class of users.

PI(-ish) "for everybody" is just not the right solution for non-technical-
savy users that would just not know that these funny numbers they received
from one of their providers are relevant, and lose them - thus, when changing
providers, would get new ones anyway.  And what do they need static addresses
for, anyway, as long as some sort of "register and lookup" mechanism exist
(mDNS, DNS, SIP, ...) to find the address when needed?

No, Owen's home does not qualify for a typical "SOHO" network, and most
likely, none of the other readers.  Ask yourself, what is needed to make
the network on your parent's home work (assuming those are not network
engineers).

Gert Doering
        -- NetMaster
--

-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

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

Fred Baker (fred | 22 Oct 02:09 2014
Picon

IETF 91 Preliminary Agenda

Lee and I have come up with a draft agenda. It has two documents on it that have not yet been updated; if they
aren’t updated by the filing deadline, we’ll be taking them off the agenda. If new drafts are filed by
the deadline and we see working group interest, we will adjust for that as well.

The filing deadline is 2014-10-27 (Monday) UTC 23:59.

http://www.ietf.org/proceedings/91/agenda/agenda-91-v6ops

Draft authors, we need to know whom to expect to be presenting, and we need whatever slides you expect to use.
We are planning about half an hour per draft, which we expect to be at least half discussion.
_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops
Tim Chown | 21 Oct 16:30 2014
Picon

Re: I-D Action: draft-ietf-v6ops-6to4-to-historic-06.txt



Tim

On 21 Oct 2014, at 11:29, Gert Doering <gert-BgGAxIuQBdJeoWH0uzbU5w@public.gmane.org> wrote:

Hiya,

On Mon, Oct 20, 2014 at 11:38:29PM -0700, internet-drafts-EgrivxUAwEY@public.gmane.org wrote:
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Operations Working Group of the IETF.

       Title           : Deprecating Connection of IPv6 Domains via IPv4 Clouds (6to4)
       Authors         : Ole Troan
                         Brian Carpenter
Filename        : draft-ietf-v6ops-6to4-to-historic-06.txt

Support.  Both for the cause as for the text as written.

It's good to see a respin of the draft, taking into account recent
developments in clients (HE) and networks (6rd) and making clear which
parts are problematic, and which "similar-looking" parts are not
(namely, 6rd, and non-relay-using 6to4 between two IPv4-only hosts)

Yes, very much so.

In the last bullet point of section 3, might add “, as is becoming increasingly common as ISPs who are unable to acquire additional globally unique IPv4 address space turn to CGN.” or words to that affect.

Anything to say about the use of the prefix in address selection policy tables (noting that 3ffe::/16 is still cited there)?

There’s a paragraph at the end that says:

  "Peer-to-peer usage of the 6to4 mechanism, not depending on the
anycast mechanism, might exist in the Internet, largely unknown to operators. This is harmless to third parties and the current document is not intended to prevent such traffic continuing."

which is a little at odds with the Historic status for 3056? If it’s made historic, and support removed, it would harm them…?

Tim
_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops
Lorenzo Colitti | 21 Oct 13:42 2014
Picon

Re: draft-ietf-v6ops-dhcpv6-slaac-problem WGLC

On Tue, Oct 21, 2014 at 3:12 AM, 神明達哉 <jinmei <at> wide.ad.jp> wrote:
I have a mixed feeling about the importance of the document.  I
personally don't think it worth publishing in its current form,
although I wouldn't be opposed to it if the wg thinks it's useful.

+1. The operational problems section boils down to one statement: "if you flash renumber, the results differ between operating systems" (i.e., section 3.2.2). That's a true statement, but pretty obvious from the preceding text.

The only other operational problems statement, in section 3.2.1, is not very useful: if you don't have addresses via DHCPv6 or SLAAC, then there's little point getting other information from DHCP. For this to work at all, IP addresses must be configured manually, and if you're using manual configuration, you might as well configure other information manually as well.

The rest of the draft before the appendix is a rehash of RFC 4862, which doesn't really add anything new.

On the other hand, the appendix, which documents the behaviour of various OSes under different conditions, is useful.

Given that, it would seem to make more sense for this document to focus only on the results of the investigation (i.e., only the appendix), and a concluding statement that notes that implementations differ in their behaviour, and that renumbering behaviour is substantially different.
_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops
Liubing (Leo | 21 Oct 05:25 2014

Re: draft-ietf-v6ops-dhcpv6-slaac-problem WGLC

Hi Jinmei,

Thanks for your comments. Please see replies inline.

> -----Original Message-----
> From: v6ops [mailto:v6ops-bounces <at> ietf.org] On Behalf Of 神明達哉
> Sent: Tuesday, October 21, 2014 2:13 AM
> To: Fred Baker (fred)
> Cc: v6ops <at> ietf.org
> Subject: Re: [v6ops] draft-ietf-v6ops-dhcpv6-slaac-problem WGLC
> 
> At Sun, 19 Oct 2014 11:00:02 -0700,
> fred <at> cisco.com wrote:
> 
> > This is to initiate a two week working group last call of
> > http://tools.ietf.org/html/draft-ietf-v6ops-dhcpv6-slaac-problem.

> > Please read it now. If you find nits (spelling errors, minor suggested
> > wording changes, etc), comment to the authors; if you find greater
> > issues, such as disagreeing with a statement or finding additional
> > issues that need to be addressed, please post your comments to the
> > list.
> >
> > We are looking specifically for comments on the importance of the
> > document as well as its content. If you have read the document and
> > believe it to be of operational utility, that is also an important
> > comment to make.
> 
> I have a mixed feeling about the importance of the document.  I personally
> don't think it worth publishing in its current form, although I wouldn't be
> opposed to it if the wg thinks it's useful.
> 
> Vagueness and ambiguity regarding M, O, and A flags (especially the first two)
> are well known, and it's not surprising that different implementations behave
> differently.  Since such a divergence can cause a critical operational issue, I
> see a value in documenting these.
[Bing] I believe it is well known among standard developers, participants and implementers who had paid
attention on it. However, since the ambiguity problem is not so explicit in current standard, the vast
administrators/operators out IETF might not quite familiar with it. I once talked with some operator
people, they were quite confused about the situation when they met the problem in their IPv6 testbed
networks. 
So, if there is an RFC explicitly stating the problems, I think it would be good for
administrators/operators to learn the fact before they actually deploying the networks. Also, the
document could be a formal reference for potential standard work in the future to clear the ambiguity in
current standards.

> On the other hand, the specific issues described in Section 3.2 don't seem to
> be very critical to me.
[Bing] I agree the issues might not be critical for some people. But maybe they are important concerns in
other situations. Considering we are just at the beginning stage of deploying IPv6, It might be hard for us
to judge the importance, but we could document the issues, at least it is not harmful. 

> In the case described in Section 3.2.1, the host would only have link-local
> addresses. 
[Bing] Or maybe self-generated ULAs. (But of course, it is not the point of this document.)

> Such a host wouldn't be able to do many useful things anyway
> (potentially, there may be some interesting scenarios for a completely
> isolated, single-link, autonomous network with only link-local addresses, but
> I suspect there are many other fundamental issues to solve for such
> environments before we even worry about the M/O/A flags).
[Bing] I agree there would be other fundamental issues, but the O flag behavior would also exist anyway.

> The issues described in Section 3.2 seem to be caused largely because they
> switch the address configuration mechanism (SLAAC to DHCPv6 or vice versa)
> in addition to renumbering.  While that could happen in theory, it seems to
> be a quite artificial discussion.
[Bing] The address configuration mechanism switching is a specific case of renumbering; another one is to
add a new address by DHCPv6 for the already SLAAC-configured hosts or vice versa. These use cases might
happen in enterprise networks when companies split, merge, grow, relocate, or reorganize. 

> Actually, I guess there should be more pragmatic examples of operational
> issues because of the described divergence and I wonder whether these
> minor cases are really the only things we can imagine (although I don't have
> a specific idea right now).  If these sections can be revised with more
> convincing examples, I would be more supportive about publishing it.
[Bing] Current draft only documents the operational issues caused by divergent behaviors identified in
the tests. In Appendix B, it documents a comprehensive analysis of the ambiguity. If we made a permutation
and combination of the divergence derived from the ambiguity analysis, there would be other divergence
that did not covered in our limited tests (focusing on current mainstream desktop/phone OSes). But since
it is only in theory, we just left it in the appendix as a hint to the administrators.

> Some specific comments (mostly editorial and nits) on the draft text:
> 
> - Section 1:
> 
>    The M, O and A
>    flags are advisory, not prescriptive.
> 
>   In my understanding, the A flag is quite prescriptive.  If a host
>   implementation doesn't perform SLAAC for a prefix information option
>   with A flag on, that implementation would be considered
>   non-compliant.  At the very least, the level of "advisory" vs
>   "prescriptive" is much different between M,O and A, so listing all
>   of them in this sentence seems to be misleading, if not simply
>   incorrect.
[Bing] A flag in definition is not prescriptive, RFC4862 only explicitly defined " If the Autonomous flag
is not set, silently ignore the Prefix Information option." 
However, A flag in implementations (as we tested) is prescriptive, and I also agree it should be. We might
need to be distinguish the description between the A/M/O flags.
Thanks for the good point.

> - Section 2.1: s/setting/settings/
> 
>    [...]  The following setting are all allowed:
> 
> - Section 2.2: s/setting/settings/
> 
>    [...]  The following setting are all
>    allowed:
[Bing] We'll revise accordingly. Thank you.

Best regards,
Bing

> --
> JINMEI, Tatuya
> 
> _______________________________________________
> v6ops mailing list
> v6ops <at> ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops
fred | 19 Oct 20:00 2014
Picon

draft-ietf-v6ops-dhcpv6-slaac-problem WGLC

This is to initiate a two week working group last call of
http://tools.ietf.org/html/draft-ietf-v6ops-dhcpv6-slaac-problem.  
Please read it now. If you find nits (spelling errors, minor suggested
wording changes, etc), comment to the authors; if you find greater
issues, such as disagreeing with a statement or finding additional
issues that need to be addressed, please post your comments to the
list.

We are looking specifically for comments on the importance of the
document as well as its content. If you have read the document and
believe it to be of operational utility, that is also an important
comment to make.

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


Gmane