Fernando Gont | 1 Sep 03:17 2015
Picon

Why operators filter IPv6 packets with extension headers?

Folks,

The topic of operators dropping IPv6 packets containing extension
headers has been raised quite a few times on this list and elsewhere.

A month ago or so we published a document trying to summarize the
reasons for which operators filter IPv6 packets containing extension
headers. The document is available at:
<https://tools.ietf.org/id/draft-gont-v6ops-ipv6-ehs-packet-drops-00.txt>

We're currently working on a revision of this document, and would like
to hear feedback from the working group regarding our document. e.g.,

* Did we get anything wrong?
* Is there anything missing?

Or, if you like the document and agree with its content, that's also
interesting feedback to have.

Thanks!

Best regards,
--

-- 
Fernando Gont
e-mail: fernando@... || fgont@...
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

_______________________________________________
v6ops mailing list
v6ops@...
(Continue reading)

fred | 30 Aug 20:00 2015
Picon

draft-ietf-v6ops-reducing-ra-energy-consumption 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

internet | 29 Aug 22:55 2015
Picon

I-D Action: draft-ietf-v6ops-pmtud-ecmp-problem-04.txt


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           : Close encounters of the ICMP type 2 kind (near misses with ICMPv6 PTB)
        Authors         : Matt Byerly
                          Matt Hite
                          Joel Jaeggli
	Filename        : draft-ietf-v6ops-pmtud-ecmp-problem-04.txt
	Pages           : 8
	Date            : 2015-08-29

Abstract:
   This document calls attention to the problem of delivering ICMPv6
   type 2 "Packet Too Big" (PTB) messages to the intended destination
   (typically the server) in ECMP load balanced or anycast network
   architectures.  It discusses operational mitigations that can be
   employed to address this class of failures.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-pmtud-ecmp-problem/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-v6ops-pmtud-ecmp-problem-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-pmtud-ecmp-problem-04

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)

Liushucheng (Will | 28 Aug 05:51 2015

Review for draft-ietf-v6ops-host-addr-availability

Hi all,

After taking a look at this draft, I feet it practical and agree to the point, with some comments below (most
are clarifying ones).

Section 4:
>   Assigning a limited number of addresses per host implies that
>   functions that require multiple addresses will either be unavailable
>   (e.g., if the network provides only one IPv6 address per host, or if
>   the host has reached the limit of the number of addresses available),
>   or that the functions will only be available after an explicit
>   request to the network is granted.  The necessity of explicit

Could you explicitly point out which "functions" or add a reference?

Section 6:
>    o  Using Stateless Address Autoconfiguration [RFC4862].  SLAAC allows
>       hosts to create global IPv6 addresses on demand by simply forming
>       new addresses from the global prefix assigned to the link.

Traditional slaac only allows for a single stable address, since the address is generated by embedding the
underlying mac address.

>  It is also possible for a client to
>       request additional addresses using a different DUID.

Would this really comply with the spirit of DHCPv6?

> Immune to layer 3 on-  |    No   |    Yes     |   Yes   |   Yes   |
>    | link resource          |         |            |         |         |
(Continue reading)

Alberto Leiva | 26 Aug 18:23 2015
Picon

What do I do with untranslatable IPv4 addresses?

Because all it does is prepend a prefix, the address translation
algorithm from RFC 6052 can take any IPv4 address as input and
generate an IPv6 address as a result.

Because it depends on an input IPv6 address containing the prefix, the
opposite is not true: It cannot generate an IPv4 address out of *any*
IPv6 address.

I think this is the reason why RFC 6791 requires an IPv4 address pool
but doesn't even mention an IPv6 pool; assuming RFC 6052 is the only
address translation algorithm at play, any IPv4 router will source
ICMPv4 errors in translatable ways. It's IPv6 routers that need to be
masked with special IPv4 addresses.

If we're defining new address translation algorithms, I think we risk
breaking this assumption. In particular, EAM breaks it. It is entirely
possible to configure an EAM table where not every IPv4 address is
translatable. (ie. pretty much any EAMT that doesn't include
0.0.0.0/0)

Now, it's true that EAM can be used in concert with RFC 6052
translation (therefore making every IPv4 address translatable), but
Tore and I agree that there are use cases where EAM can be used
without the 6052 falling back option
(https://mail-lists.nic.mx/pipermail/jool-list/2015-August/000041.html).
For this reason, it would be asinine for an implementation to force
the presence of a 6052 prefix in the configuration as long as there is
at least one entry in the EAMT. This *could* (though in SIIT/DC it
doesn't seem to be an issue) lead to a situation where an IPv4 router
answers an ICMPv4 error and the translator will have to drop it
(Continue reading)

fred | 23 Aug 20:00 2015
Picon

draft-ietf-v6ops-reducing-ra-energy-consumption WGLC

This is to initiate a two week working group last call of
http://tools.ietf.org/html/draft-ietf-v6ops-reducing-ra-energy-consumption.  
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

Stephen Farrell | 19 Aug 14:50 2015
Picon
Picon

Stephen Farrell's No Objection on charter-ietf-v6ops-03-00: (with COMMENT)

Stephen Farrell has entered the following ballot position for
charter-ietf-v6ops-03-00: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-v6ops/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Definitely ready for external review. Could also be just fine to
re-charter,
not sure what's intended.

This is though a pretty vague charter and mostly seems to characterise
what won't be done instead of what is planned to be done. I'm ok with
that given that the WG seems to have a bunch of work to do and doesn't
seem to have gone crazy in the past.

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

Lin, Ping (Ping | 17 Aug 21:50 2015

Question re. destination cache entry in Neighbor Discovery

Hi Everyone,

 

I wonder if you could help with a couple of questions related to destination cache management in IPv6 Neighbor Discovery:

 

-          It appears from testing on Windows 7  devices that if a prefix is removed on a router to which the device is connected, traffic stops as soon as the prefix is deleted, even though the destination cache entry is not removed.  Is this behavior expected?

-          After one minute, the destination cache entry is removed.   Is there an RFC reference defining the lifetime of destination cache entries?

 

Regards,

Ping Lin

Avaya

 

_______________________________________________
v6ops mailing list
v6ops@...
https://www.ietf.org/mailman/listinfo/v6ops
Spencer Dawkins | 17 Aug 18:20 2015
Picon

Spencer Dawkins' No Objection on charter-ietf-v6ops-03-00: (with COMMENT)

Spencer Dawkins has entered the following ballot position for
charter-ietf-v6ops-03-00: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-v6ops/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

This looks like a fine revised charter. I had slight uneasiness about
adding 

"2.  Solicit input from network operators and users to identify
operational interaction issues with the IPv4 Internet, and determine
solutions or workarounds to those issues."

because I wondered if this will make v6ops more attractive for NAT
proposals, but if that's the right thing to do, please do the right
thing.

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

fred | 16 Aug 20:00 2015
Picon

draft-ietf-v6ops-siit-dc-2xlat 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

Xing Li | 12 Aug 02:47 2015
Picon

New Version Notification for draft-bao-v6ops-rfc6145bis-01.txt

Hi, All,

According to the conclusion made in v6ops meeting of IETF93, (removing
the EAM part and refer to EAM draft), we have updated the
draft-bao-v6ops-rfc6145bis, please review. Thanks.

Regards,

xing

> Name:		draft-bao-v6ops-rfc6145bis
> Revision:	01
> Title:		IP/ICMP Translation Algorithm (rfc6145bis)
> Document date:	2015-08-07
> Group:		Individual Submission
> Pages:		38
> URL:            https://www.ietf.org/internet-drafts/draft-bao-v6ops-rfc6145bis-01.txt
> Status:         https://datatracker.ietf.org/doc/draft-bao-v6ops-rfc6145bis/
> Htmlized:       https://tools.ietf.org/html/draft-bao-v6ops-rfc6145bis-01
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-bao-v6ops-rfc6145bis-01
>
> Abstract:
>    This document describes the Stateless IP/ICMP Translation Algorithm
>    (SIIT), which translates between IPv4 and IPv6 packet headers
>    (including ICMP headers).  This document updates RFC 6145.
>
>                                                                                   
>   

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


Gmane