Aijun Wang | 23 Jul 07:35 2014
Picon

Re: Comments on draft-wang-v6ops-flow-label-refelction-01

Hi, Brain:

Thanks for your comments. Below is my opinion to your concern points.
1. If some session support reflection, and others not, then the unsupported
session will be less likely recognized and controlled, there is no other
side-effect. Packets in bi-direction will be load balanced according to the
RFC6438, regardless whether the IPv6 flow label is reflected or not.
2.The reason that the IPv6 flow label is not supported in the real world is
that we have not find some killer-application that can exploit this field.
The mechanism of IPv6 flow label reflection can increase the opportunities
of such killer-application be hatched, not the contrary.
3. For mechanism of IPv6 flow label reflection, we strongly recommend this
value be manipulated only at the IPv6 packet endpoints, not the in-path
device. What is the motion for firewalls to rewrite this value?
4.The session for flow label can be UDP request/reply or TCP request/reply.
If one same client have multiple Http connections, there will be multiple
distinctive IPv6 Flow label. That is to say, this value is unique in the
local host for every TCP/UDP session.
5.For In-path device, it needs actually 3-tuple {Flow Label, Source Addr,
Destination Addr} to identify the unique session. If the flow label be
reflected, then the same 3-tuple can used to identify bi-direction traffic
of this session, or else it needs two different 3-tuple, or to parse the
extend IPv6 header.
6. Considering on-path attack, I think we can view this value as one magic
number, which is widely used in various application protocol. This magic
number/IPv6 flow label will be used only to coordinate the bi-direction
traffic of one session. If it is changed by some on-path attacker, it only
influence the recognition accuracy and control of the session. For
differentiated service based on this value, we need other mechanism to
protect or authenticate it. It is same risk for differentiated services that
(Continue reading)

Aijun Wang | 23 Jul 07:40 2014
Picon

Re: Comments on draft-wang-v6ops-flow-label-refelction-01

Hi, Brain:

Thanks for your comments. Below is my opinion to your concern points.
1. If some session support reflection, and others not, then the unsupported
session will be less likely recognized and controlled, there is no other
side-effect. Packets in bi-direction will be load balanced according to the
RFC6438, regardless whether the IPv6 flow label is reflected or not.
2.The reason that the IPv6 flow label is not supported in the real world is
that we have not find some killer-application that can exploit this field.
The mechanism of IPv6 flow label reflection can increase the opportunities
of such killer-application be hatched, not the contrary.
3. For mechanism of IPv6 flow label reflection, we strongly recommend this
value be manipulated only at the IPv6 packet endpoints, not the in-path
device. What is the motion for firewalls to rewrite this value?
4.The session for flow label can be UDP request/reply or TCP request/reply.
If one same client have multiple Http connections, there will be multiple
distinctive IPv6 Flow label. That is to say, this value is unique in the
local host for every TCP/UDP session.
5.For In-path device, it needs actually 3-tuple {Flow Label, Source Addr,
Destination Addr} to identify the unique session. If the flow label be
reflected, then the same 3-tuple can used to identify bi-direction traffic
of this session, or else it needs two different 3-tuple, or to parse the
extend IPv6 header.
6. Considering on-path attack, I think we can view this value as one magic
number, which is widely used in various application protocol. This magic
number/IPv6 flow label will be used only to coordinate the bi-direction
traffic of one session. If it is changed by some on-path attacker, it only
influence the recognition accuracy and control of the session. For
differentiated service based on this value, we need other mechanism to
protect or authenticate it. It is same risk for differentiated services that
(Continue reading)

Brian E Carpenter | 22 Jul 21:13 2014
Picon

Comments on draft-wang-v6ops-flow-label-refelction-01

There wasn't time for me to line up at the microphone, so
here are my comments. I think the idea is quite interesting,
but a little optimistic.

What are the effects of some sessions supporting reflection
and others not? We know very well that even the basic RFC 6437
flow label is not supported yet in the real world, so widespread
use of reflection is years in the future.

There's no discussion of flow label rewriting by firewalls,
which we know from the 6man discussions before RFC 6437 is
a real issue. If the scope is strictly limited to a single
administrative domain, that's OK, but the general end-to-end
case probably fails.

Actually, the draft doesn't clarify exactly what is a session
for flow label purposes. As noted in the meeting, is a "stateless"
session (UDP request/reply) a session for this purpose? What
about multiple HTTP connections from the same client?

The uniqueness rule for flow labels is that a flow is identified
by the 3-tuple {Flow Label, Source Addr, Destination Addr}. The
flow label value itself might not be unique in the intermediate
nodes, so any state must be keyed by the 3-tuple, with the two
addresses either way round.

The mechanism seems very exposed to on-path attacks, since an
attacker could forge a reverse packet with the correct label,
even before the first TCP ACK. So nobody should rely on the flow
label alone for anything important. (I don't think there is any
(Continue reading)

Liubing (Leo | 21 Jul 09:43 2014

FW: New Version Notification for draft-liu-v6ops-dhcpv6-slaac-guidance-02.txt


-----Original Message-----
From: internet-drafts@...
[mailto:internet-drafts@...] 
Sent: Monday, July 21, 2014 3:27 PM
To: Ron Bonica; Tianle Yang; Ron Bonica; Liubing (Leo); Tianle Yang; Liubing (Leo)
Subject: New Version Notification for draft-liu-v6ops-dhcpv6-slaac-guidance-02.txt

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

Name:		draft-liu-v6ops-dhcpv6-slaac-guidance
Revision:	02
Title:		DHCPv6/SLAAC Address Configuration Interaction Problem Statement
Document date:	2014-07-21
Group:		Individual Submission
Pages:		9
URL:            http://www.ietf.org/internet-drafts/draft-liu-v6ops-dhcpv6-slaac-guidance-02.txt
Status:         https://datatracker.ietf.org/doc/draft-liu-v6ops-dhcpv6-slaac-guidance/
Htmlized:       http://tools.ietf.org/html/draft-liu-v6ops-dhcpv6-slaac-guidance-02
Diff:           http://www.ietf.org/rfcdiff?url2=draft-liu-v6ops-dhcpv6-slaac-guidance-02

Abstract:
   ND and DHCPv6 protocols could have some interaction on address
   provisioning with the A, M, and O flags defined in ND protocol.  But
   the relevant standard definitions of the flags contain ambiguity, so
   that current implementations in operating systems have varied on
   interpreting the flags.  The variation might impact real network
   operations, so this document aims to provide some operational
   guidance to eliminate the impact as much as possible.
(Continue reading)

Fred Baker (fred | 14 Jul 23:30 2014
Picon

Need jabber Scribe and minutes taker for v6ops at IETF 90

Reply to v6ops-chairs@..., please.

_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops
Fred Baker (fred | 14 Jul 23:29 2014
Picon

Agenda posted

The v6ops agenda for IETF 90 has been posted, at http://www.ietf.org/proceedings/90/agenda/agenda-90-v6ops

If you want to bash the agenda, reply to this email. That will save us time in the meeting.

_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops
Andrew Yourtchenko | 11 Jul 15:16 2014
Picon

IPv6 multicast WiFi power usage - draft-desmouceaux-ipv6-mcast-wifi-power-usage

hi all,

last IETF there were presentations about ND, multicast and power usage on 
the WiFi, the consensus was we need more data on it.

Yoann did a nontrivial amount of work on this subject in the meantime and 
we'd like to show it to you and hear your feedback.

http://tools.ietf.org/html/draft-desmouceaux-ipv6-mcast-wifi-power-usage-00

thanks a lot!

--a

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

Eric Vyncke (evyncke | 10 Jul 17:06 2014
Picon

Late addition to V6OPS agenda: segment routing for IPv6?

Fred and Joel,

You may be aware of segment routing whose architecture and MPLS version are discussed in the SPRING WG. But, there is also an IPv6 version discussed in 6MAN: 
  • draft-previdi-6man-segment-routing-header
  • draft-vyncke-6man-segment-routing-security-00

It is about a modified routing extension header to allow mainly for traffic engineering and or replace a MPLS LDP core by a native IPv6 one. Hence, there is a major (we hope) operational impact.

Stefano (in cc) and I understand that we are late in the process to get a slot in V6OPS, but, if you could get us a 10-minute slot on Monday AM or Tuesday PM, then we could present what are the goals & architecture of segment routing for IPv6 (which really leverages IPv6, hence perhaps 'the killing app' for IPv6 :-))

Thanks in advance and see you in Toronto

-éric
_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops
Gert Doering | 9 Jul 12:53 2014
Picon

Re: MAC table shortage in IPv6 networks caused by multiple IPv6 prefixes/addresses//FW: New Version Notification for draft-liu-v6ops-running-multiple-prefixes-01.txt

Hi,

On Wed, Jul 09, 2014 at 10:02:51AM +0000, Liubing (Leo) wrote:
> > -----Original Message-----
> > From: Gert Doering [mailto:gert@...]
> > 
> > On Wed, Jul 09, 2014 at 08:38:13AM +0000, Liubing (Leo) wrote:
> > > In summary, the issue is that in Dual-Stack L2 networks, the hosts
> > > would cost much more MAC table space in the switch than the IPv4-only
> > > hosts. Thus in big L2 networks, there probably comes the MAC table
> > > shortage problem.
> > 
> > Uh, what?  I can see ND table overflows, but since when did hosts grew
> > extra MAC addresses for IPv6?
> 
> The scenarios is regarding L3 switches, which record "IP-MAC" pairs. 

In that case, please make this clear: this is about ND/ARP cache, not 
about "MAC table space".  The latter has a very well defined meaning, and
is very much independent from IPv4/IPv6.

> So, since hosts have multiple IPv6 addresses, they'll consume multiple "IP-MAC" records in the L3
switch. And one IPv6 record would cost 2-4 times than the IPv4 record. Thus, in dual-stack scenario, the
MAC table consumption is much higher than the IPv4 scenario.

This is *not* "the MAC table".

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
Qiong | 8 Jul 03:57 2014
Picon

Fw: New Version Notification for draft-sun-v6ops-xlat-multi-00.txt

Hi All,

We submitted a new draft about deploying multiple PLATs in 464XLAT. Your comments are more than welcome. Thanks a lot!

Best wishes
Qiong 

 
Date: 2014-07-04 21:31
Subject: New Version Notification for draft-sun-v6ops-xlat-multi-00.txt
 
A new version of I-D, draft-sun-v6ops-xlat-multi-00.txt
has been successfully submitted by Qiong Sun and posted to the
IETF repository.
 
Name: draft-sun-v6ops-xlat-multi
Revision: 00
Title: Running Multiple PLATs in 464XLAT
Document date: 2014-07-04
Group: Individual Submission
Pages: 8
 
 
Abstract:
   The IPv6 transition has been an ongoing process throughout the world
   due to the exhaustion of the IPv4 address space.  The
   464XLAT[RFC6877] provides a solution with limited IPv4 connectivity
   across an IPv6-only network, and the android system (version 2.3 and
   above) has already implemented the 464XLAT[RFC6877] and the the
   Prefix discovery solution [RFC7050].  However, the current 464XLAT
   architecture can only deal with the scenario with single PLAT in the
   network.  When operator deploys multiple PLATs with different Pref64
   prefixes, 464XLAT cannot cope with multiple prefixes for different
   destination addresses.
 
   This document describes the architecture with multiple PLATs and also
   the deployment considerations.
 
                                                                                 
 
 
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.
 
The IETF Secretariat
 
_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops
joel jaeggli | 7 Jul 18:05 2014

Drafts lodged against the deadline.

Greetings,

just a helpful reminder to folks who submitted documents right up
against the submission deadline. It is incumbent on you the authors to
draw our attention to those so that they may be discussed properly prior
to the meeting itself and agenda time can be allocated or not as necessary.

thanks
joel

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

Gmane