Subject: [BEHAVE] FW: I-D Action:draft-arkko-ipv6-only-experience-00.txt

From: Jari Arkko <[email-masked]>
Date: Tue, 06 Jul 2010 09:20:25 +0300

FYI

[email-masked]
kirjoitti:

A New Internet-Draft is available from the on-line Internet-Drafts directories.

Title : Experiences from an IPv6-Only Network
Author(s) : J. Arkko, A. Keranen
Filename : draft-arkko-ipv6-only-experience-00.txt
Pages : 17
Date : 2010-07-05

This document discusses our experiences from moving a small number of
users to an IPv6-only network, with access to the IPv4-only parts of
the Internet via a NAT64 device. The document covers practical
experiences as well as road blocks and opportunities for this type of
a network setup. The document also makes some recommendations about
where such networks are applicable and what should be taken into
account in the network design. The document also discusses further
work that is needed to make IPv6-only networking applicable in all
environments.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-arkko-ipv6-only-experience-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 06 Jul 2010 11:36:47 +0200

Hi Jari,

very interesting work, thanks for doing this.

A few questions:

section 3.1 reads

    In addition, the each NAT64 device needed another /64 prefix to be
    used for the representation of IPv4 destinations in the IPv6-only
    network.

MB> Have you tried the well-know prefix?

section 3.3. reads:

    The NAT64 devices have standard dual stack connectivity and their
    DNS64 function can use both IPv4 and IPv6 when requesting information
    from DNS.  A destination that has both an A and AAAA records is not
    treated in any special manner, because the hosts in the IPv6-only
    network can contact the destination over IPv6.  Destinations with
    only an A record will be given a synthesized AAAA record as explained
    above.  However, in one of our open visitor networks we needed a
    special arrangement.  Currently, the home network gets its IPv6
    connectivity through a tunnel via the office network, and it is
    undesirable to allow outsiders to generate traffic through the office
    network, even if the traffic is just passing by and forwarded to the
    IPv6 Internet.

MB>  I don't understand this. I mean, if the user is connected to the
IPv6 network via the office and the office find that undesirable,
it seems we have a problem no matter what... So i conclude i am not
understanding something....

    As a result, in the visitor network there is a
    special IPv6-only to IPv4-only configuration where the DNS64 never
    asks for AAAA records and always generates synthesized records.

       Note: This configuration may also be useful for other purposes.
       For instance, one drawback of standard behavior is that if a
       destination publishes AAAA records but has bad IPv6 connectivity,
       the hosts in the IPv6-only network have no fallback.  In the dual
       stack model a host can always try IPv4 if the IPv6 connection
       fails.  In the special configuration IPv6 is only used internally
       at the site but never across the Internet, eliminating this
       problem.  This is not a recommended mode of operation, but it is
       interesting to note that it may solve some issues.

MB> Your suggestion then is that the DNS64 should synthesize
AAAA RR from the A RR even in the cases where the original
answer contains real AAAA RR? Is that it?
I can see the benefit that you point out in the note if we did
so, but, the problem than is how to prefer native versus translated?

later on, it reads:

    Note that in NAT64 (unlike in its older variant [RFC4966]) it is
    possible to decouple the packet translation, IPv6 routing, and DNS64
    functions.

MB>  just to clarify, i think it is a bit more than this. The clients
are expicitly configured with the dns64 address, so they will actually
send queries to it so the ALG does not need to sniff and spoof
dns packets and does not need to be located along path. I mean,
you could have decoupled it, but still use the sniff and spoof approach.

    This was used by one of our users, as he is outside our
    physical network and wants to communicate directly on IPv6 where it
    is possible without having to go through our central network
    equipment.

MB>  this means that it has a DNS64 server locally available at its home network?

    However, to establish communications to an IPv4
    destination, our central DNS64 is used, and if there is a need to
    translate some packets, these packets find the translator device
    through normal IPv6 routing means.

MB>I don't understand this part, could you expand?

later on, in section 4, it reads:

    Firewall Issues

       We also saw a number of issues related to lack of features in IPv6
       support in firewalls.  In particular, while we did not experience
       any MTU and fragmentation problems in our networks, there is
       potential for generating problems, as the support for IPv6
       fragment headers is not complete in all firewalls and the NAT64
       specifications call for use the fragment header (even in
       situations where fragmentation has not yet occurred).

MB> do you think we should change nat64 to improve this?
i.e. try to avoid frag header as much as possible? (not sure how,
but we can try to look into that)

later on it reads:

5.4.  Appliances

    There are also problems with different appliances such as webcams.
    Many of them do not support IPv6 and hence will not work in an IPv6-
    only network.  Also not all firewalls support IPv6.  Or even if they
    do, they may still experience issues with some aspects of IPv6 such
    as fragments.

    Some of these issues are easily solved when the appliance works as a
    server, such as what most webcams and our sensor gateway devices do.
    We placed the appliance in the IPv4 part of the network, added its
    name to the local DNS, and simply allowed devices from the IPv6-only
    network reach it through NAT64.

MB> I am not sure if i fully understand this. Were the appliances
connected to the IPv4 Internet directly?
If that is the case, then fine, but this won't be possible for a
user that wants to have IPv6 only access (and maybe pay less to
its ISP). This wouldn't work if the home network has only
IPv6 access and the NAT64 is provided by the ISP.
A possible approach to avoid requiring direct access to the IPv4
Internet is to use another NAT64, between the appliances and the
home IPv6 only network. You see what i mean? Is that what you have
done?

Later on it reads:

    When the sites were accessed from IPv6-only network via a NAT64
    device, the failure rate increased to 2.1%.

MB> this is really good, isn't it?

Regards, marcelo

El 06/07/10 8:20, Jari Arkko escribió:
> FYI
>
> [email-masked] kirjoitti:
>> ------------------------------------------------------------------------
>>
>> Internet-Draft directories:http://www.ietf.org/shadow.html
>> orftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>    
>
>
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
>

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 6 Jul 2010 12:34:58 +0200

> FYI

Good stuff, Jari.

However, the title doesn't really cover the content, as NAT64 is not mentioned in the title. This could be confusing.

I would also mention that using a dual stack HTTP proxy is an easy way for IPv6-only systems to reach IPv4 literals over HTTP.

Too bad you didn't look at bittorrent, this is pretty much a horror story.

Iljitsch

---

From: Jari Arkko <[email-masked]>
Date: Wed, 07 Jul 2010 11:54:43 +0300

Iljitsch,

> Good stuff, Jari.

Thanks for your feedback!

> However, the title doesn't really cover the content, as NAT64 is not mentioned in the title. This could be confusing.

We'll consider this. There's really multiple components in our setup -- 
running on IPv6-only local network, doing our 
local/IETF/googling/facebookking services over IPv6, having a NAT64 
somewhere on the path to the global Internet, and so on.

> I would also mention that using a dual stack HTTP proxy is an easy way for IPv6-only systems to reach IPv4 literals over HTTP.

Yes it is. We should add more pointers to alternative configurations. 
(Btw, is there a convenient IETF RFC that discusses the IPv6-only web 
proxy setup?)

> Too bad you didn't look at bittorrent, this is pretty much a horror story.

Bittorrent and other P2P stuff is on our list of things to do. I would 
love to download^H^H^H^H^H^H^H^H know what happens. Have you tried since 
you say its a horror story?

Jari

---

From: Jari Arkko <[email-masked]>
Date: Wed, 07 Jul 2010 12:11:35 +0300

marcelo,

> very interesting work, thanks for doing this.

Thanks for your comments.

> MB> Have you tried the well-know prefix?

We did not use it, but you are right. This should be mentioned or 
perhaps even recommended.

> understanding something....

Clearly, the draft needs some work to explain this better. In any case, 
we have two sets of users. One set of users is known and trusted. We can 
route their traffic through the office (my ISP does not offer native 
IPv6, though other ISPs in the area do. So I am using the Ericsson 
office for my IPv6 service over a tunnel.) Then there are random people 
who connect through my open access point. I don't want to route their 
traffic through the office.

> answer contains real AAAA RR? Is that it?

Yes.

> so, but, the problem than is how to prefer native versus translated?

In this case there is *no* native connectivity. In that particular 
network I'm not letting any IPv6 traffic out. So we are only 
synthesizing... I hope you now understand why I'm saying that this is 
not a recommended model.

> you could have decoupled it, but still use the sniff and spoof approach.

Right. The draft needs to be clarified regarding this.

> MB>  this means that it has a DNS64 server locally available at its 

Clarification is needed here as well. He uses a central DNS64 server, 
but does not want to route all data packets through our network via a 
tunnel or something like that. So, if he gets a native AAAA record his 
traffic is going direct from his computer to the destination. Its only 
if he gets a synthesized AAAA record that he has to route a data packet 
through the central network.

> but we can try to look into that)

Possibly, but I need to talk to our packet translation guy as he returns 
from vacation. I don't remember all the details.

> connected to the IPv4 Internet directly?

In this case it was not connected to the IPv4 Internet, it was in the 
local dual stack network as an IPv4-only device. But what matters is 
that the device was on the dual stack side of the NAT64 device, and 
hence my IPv6-only devices can connect to the device through the NAT64.

> home IPv6 only network. You see what i mean? Is that what you have

I agree that it would be possible, but its not what I have done. There 
are obviously many different possible configurations and use cases. In 
my case I only needed to talk to these devices from other devices in my 
home, so all this would work even if my Internet connection was 
IPv6-only, because I can use private IPv4 address space at home. Again, 
the NAT64 can help my IPv6-only devices connect to the IPv4-only 
devices, be they in the global Internet or in my private network.

> MB> this is really good, isn't it?

Yes -- that part of the user experience was excellent. There has been no 
major issues or even differences in my web browsing experience, for 
instance.

Jari

---

From: Reinaldo Penno <[email-masked]>
Date: Wed, 7 Jul 2010 05:11:47 -0400

Hello Jari,

This is a good document and the presentation at the IPv6 conference was
quite interesting. I have one question on the web browsing experience:

Besides recreational (facebook, twitter, etc) and work related web browsing,
have you tried things like:

* Paying bills through one or more secure online banking websites
* Buying something at Amazon or related
* Using Google's/Bing's map engine with layers and details turned on
* Watching video on demand from a website like Hulu (or the local
equivalent) as opposed to youtube.

A couple of questions regarding VoIP:

You said you did not employ ALGs but FTP.

* In the case of VOIP, was SIP ever tested?
* If yes, how was the traversal done?
* In general for all VoIP, were calls place from IPv6 to IPV4 and
vice-versa?

Thanks,

Reinaldo

On 7/5/10 11:20 PM, "Jari Arkko" <[email-masked]> wrote:

> FYI
> 
> [email-masked]<mailto:[email-masked]> kirjoitti:
> 
> ________________________________
> 
> [email-masked]<mailto:[email-masked]>

---

From: Jari Arkko <[email-masked]>
Date: Wed, 07 Jul 2010 12:36:43 +0300

Reinaldo,

> quite interesting.

Thanks!

> I have one question on the web browsing experience:
>

Yes

(For this and the below answer's I'm just answering for myself. There 
are a few other people in the test as well, but I don't know exactly 
what their browsing habits have been.)

> * Buying something at Amazon or related

Yes, though I have not kept records of which services I have used, but I 
have used at least Amazon. I do buy quite a lot from the web though and 
never had a problem.

> * Using Google's/Bing's map engine with layers and details turned on

Yes, on Google but I have not tried Bing. Let me try... I seem to be 
able to play with it and I don't see any problems.

> equivalent) as opposed to youtube.

I have watched videos from Youtube and many other places. Not Hulu 
though... let me try. Hmm... "Sorry, currently our video library can 
only be streamed from within the United States ". Oh well, I'll try this 
again when I'm in the US the next time.

> * In general for all VoIP, were calls place from IPv6 to IPV4 and

No, we have not tried VoIP beyond Skype and Gtalk yet.

Just like P2P, SIP stuff is on our list of things to try. (Doesn't SIP 
need an ALG even for NAT44?)

Jari

---

From: Reinaldo Penno <[email-masked]>
Date: Wed, 7 Jul 2010 05:57:04 -0400

Yes, SIP most often than not needs an ALG.

I was also wondering about RTSP and video streaming...even though HTTP has
taken over as the streaming protocol of the Internet.

But your answers about secure websites are most encouraging. In the past
I've seen some Java(Script)/ActiveX used by some secure sites complain.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 7 Jul 2010 13:36:58 +0200

> Yes it is. We should add more pointers to alternative configurations. (Btw, is there a convenient IETF RFC that discusses the IPv6-only web proxy setup?)

Not that I know of...

> Bittorrent and other P2P stuff is on our list of things to do. I would love to download^H^H^H^H^H^H^H^H know what happens. Have you tried since you say its a horror story?

Well, I'm not 100% sure what the current situation is. But way back when the BitTorrent protocol was created, this was done in an IP version agnostic way: the tracker (the central server that tells the peers other peers' addresses) could handle both IPv4 and IPv6 addresses as well as FQDNs. At this point, I don't think anyone actually ran BitTorrent over IPv6.

However, these lists of peers were quite large in this format (which was text, I believe), so this was optimized later as an update to the protocol so the peer addresses are transferred as lists of 32-bit words in binary, which of course isn't compatible with IPv6.

Then, the Pirate Bay, which used to operate a huge tracker which was used widely, added IPv6. So implementations that were written with IPv6-agnostic APIs (such as Java) would connect over IPv6 with unexpected results because no IPv4 address was seen for these peers. To solve this, the Pirate Bay and the developers of their tracker software (I seem to remember "opentracker" but that term gives way too many Google hits) decided that client/tracker communication would happen over two sessions: one for IPv4 over IPv4 and one for IPv6 over IPv6.

Some IPv6-capable client developers added this to their clients, and life was good. For them at least, because anyone with IPv6 and an older IP version agnostic client (such as the old BitTorrent Inc python implementation) was unable to use the Pirate Bay tracker because the tracker wouldn't provide information about IPv4 peers over IPv6 and/or there would be protocol failure. At this point, the Pirate Bay put their IPv4 and IPv6 user numbers on their homepage, which was something like 30 million IPv4 vs 20000 IPv6 or something like that.

What I saw around this time was that a limited amount of IPv6 peers could be discovered through the DHT that compliments the tracker mechanism. The vast majority of these peers would be 6to4 addresses, which would virtually never accept incoming sessions.

And then the Pirate Bay started to have serious legal problems and found itself rehosting several times. At some point, their IPv6 support was quietly killed. They also started a PR offensive to get rid of trackers completely, saying that they are now no longer necessary (and of course a legal liability) as many clients now implent DHT peer discovery.

Now all of this has been and probably still is subject to change and I haven't kept up with the details, but now whenever I look I never see any IPv6 peers.

---

From: Jari Arkko <[email-masked]>
Date: Wed, 07 Jul 2010 17:32:06 +0300

Iljitsch,

> Now all of this has been and probably still is subject to change

Thanks for the information. This is definitely interesting, and there 
are plenty of opportunities to test -- on dual stack networks, on 
ipv6-only, on ipv6-only + nat64, actual capabilities of peers 
advertising IPv6, different p2p brands, and so on. We will do some 
testing, but it would be great to see some other results as well (e.g., 
on pure dual stack).

Jari

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 7 Jul 2010 16:44:04 +0200

On 7 jul 2010, at 16:32, Jari Arkko wrote:

> Thanks for the information. This is definitely interesting, and there are plenty of opportunities to test -- on dual stack networks, on ipv6-only, on ipv6-only + nat64, actual capabilities of peers advertising IPv6, different p2p brands, and so on. We will do some testing, but it would be great to see some other results as well (e.g., on pure dual stack).

An interesting aside: the bittorrent type of peer-to-peer has a really good IPv6 deployment model: only a relatively small fraction of the peers needs to be dual stack and the majority can be IPv4-only or IPv6-only, and still everyone will get all the data.

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 7 Jul 2010 09:54:23 -0700

...
> need an ALG even for NAT44?)

No.  Vonage (which uses SIP) doesn't need an ALG because all traffic
goes to their servers (and pinholes are opened by virtue of the Vonage
SIP client sending RTP packets).  Yahoo's 'messenger' application does 
voice and video and uses SIP under the covers (it's SIP inside of XML, 
you can see it with a sniffer trace), and uses ICE for its NAT traversal.

Same with Apple's Facetime (it uses SIP and ICE for NAT traversal), 
which would be interesting to test on an IPv6-only network, too.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 7 Jul 2010 09:57:39 -0700

> are plenty of opportunities to test -- on dual stack networks, on ipv6-
> only, on ipv6-only + nat64, actual capabilities of peers advertising
> IPv6, different p2p brands, and so on. We will do some testing, but it
> would be great to see some other results as well (e.g., on pure dual
> stack).
> 
> An interesting aside: the bittorrent type of peer-to-peer has a really
> good IPv6 deployment model: only a relatively small fraction of the
> peers needs to be dual stack and the majority can be IPv4-only or IPv6-
> only, and still everyone will get all the data.

But only if the file you want is hosted by someone on the same IP address
family as yourself, correct?  That is likely with larger swarms, but
less likely with smaller swarms.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 7 Jul 2010 10:01:35 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Jari Arkko
> Sent: Wednesday, July 07, 2010 1:55 AM
> To: Iljitsch van Beijnum
> Cc: Behave WG
> Subject: Re: [BEHAVE] FW: I-D Action:draft-arkko-ipv6-only-experience-
> 00.txt
> 
> Iljitsch,
> 
> > Good stuff, Jari.
> >
> 
> > However, the title doesn't really cover the content, as NAT64 is not
> mentioned in the title. This could be confusing.
> >
> 
> > I would also mention that using a dual stack HTTP proxy is an easy
> way for IPv6-only systems to reach IPv4 literals over HTTP.
> >
> 

http://tools.ietf.org/html/draft-wing-behave-http-ip-address-literals-02

-d

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 7 Jul 2010 19:06:15 +0200

> family as yourself, correct?

No, that's not necesary. Suppose you are IPv4-only, Jari is IPv6-only (his NAT64 is in the shop being updated to conform to the latest spec) and I'm dual stack. Now you seed the file and Jari and me want to download it. Initially Jari will be unsuccesful because he can't connect to you, but I can download from you and once I have the data Jari can download from me.

The important difference between SIP-like P2P and BitTorrent-like P2P is that with SIP, you need to be able to talk to any and all peers, with BitTorrent you just need an indirect connection towards the minimum group of peers that together have the entire file, so it's ok if there are peers you can't talk to directly.

Iljitsch

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 7 Jul 2010 10:06:32 -0700

> * Paying bills through one or more secure online banking websites

Just paid a bill using my banks online billpay service (SSL) from
IPv6-only + nat64, no issues.

> * Buying something at Amazon or related

Amazon has IPv4 literals in their streaming video service.  I have
report this to them, but no feedback .... My NAT-PT / NAT64 vendor has
documented issues with javascript which i hope they will fix.  The
Ericsson solution does not have these javascript issues.

> * Using Google's/Bing's map engine with layers and details turned on

Works, both.  Google is native v6, Bing via NAT64 with no issues.

> equivalent) as opposed to youtube.

Hulu via NAT64 and Youtube native, both work fine.

I started using IPv6-only on a Nokia Nuron (5230) in march and have
not used IPv4 since.  On the Symbian platform, i feel the user
experience is 99% the same as IPv4 and going IPv6-only as a the
service will not put the customer at any disadvantage.  My primary
uses are web and email, both work flawlessly with native ipv6 as well
as via the nat64.  There are some known apps that fail, but i believe
users will find good substitutes for the failed apps and the companies
that do not update their apps to be IP version agnostic will lose
business.

If you are in the USA and a T-Mobile USA subscriber with a Nokia
phone, please feel free to contact me off list to join our beta
service of IPv6-only.  I am happy to receive feedback on how the
service performs and how it can be improved before we do a commercial
launch.

Thanks,

Cameron

ps.  I wrote and sent this mail from ipv6-only + nat64 :)

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 7 Jul 2010 10:25:04 -0700

> From: Iljitsch van Beijnum [mailto:[email-masked]]
> Sent: Wednesday, July 07, 2010 10:06 AM
> To: Dan Wing
> Cc: 'Jari Arkko'; 'Behave WG'
> No, that's not necesary. Suppose you are IPv4-only, Jari is IPv6-only
> (his NAT64 is in the shop being updated to conform to the latest spec)
> and I'm dual stack. Now you seed the file and Jari and me want to
> download it. Initially Jari will be unsuccesful because he can't
> connect to you, but I can download from you and once I have the data
> Jari can download from me.

So, Jari can download from you because you (and him) are both IPv6.

> The important difference between SIP-like P2P and BitTorrent-like P2P
> is that with SIP, you need to be able to talk to any and all peers,
> with BitTorrent you just need an indirect connection towards the
> minimum group of peers that together have the entire file, so it's ok
> if there are peers you can't talk to directly.

I wouldn't quite say it that way; it needs a connection to a peer that
has the necessary pieces and running the same IP address family.  

-d

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 7 Jul 2010 19:59:08 +0200

> has the necessary pieces and running the same IP address family.  

Yes, but assuming there are some multi-stack peers eventually peers of all IP versions will in principle be able to find a peer with the same IP version that has the necessary pieces. Of course there is always room for complications, for instance if all the peers of one IP version are unable to receive incoming sessions.

It would be interesting to see how BitTorrent works though a NAT64. An old IP version agnostic client will probably do fine, but a new one that expects IPv4 peer addresses over an IPv4 session and IPv6 peer addresses over an IPv6 session will have trouble, depending on how flexible it is. (An example of the former would be the the Azureus 2.5.something or older client, the latter the latest Vuze.)

---

From: Hui Deng <[email-masked]>
Date: Thu, 8 Jul 2010 10:38:58 +0800

Hi Jari

I read through the document and discussion down here, and would like to say
it is a good reference
document which should exist here.

We are working on the open source for BIH solution which in the host
http://tools.ietf.org/html/draft-huang-behave-bih-00.html
Hope we could do some experiement and adding some result in your future
document update.
Comment to your basic document, I guess ALG and referal have become major
challenge for IPv6 translation
we may need to work on this in the future which will benefit for IPv6
migration

Many thanks

-Hui

2010/7/6 Jari Arkko <[email-masked]>

> A URL for this Internet-Draft is:http://www.ietf.org/internet-drafts/draft-arkko-ipv6-only-experience-00.txt
>
> Internet-Drafts are also available by anonymous FTP at:ftp://ftp.ietf.org/internet-drafts/
>
> ------------------------------
>
> I-D-Announce mailing [email-masked]://www.ietf.org/mailman/listinfo/i-d-announce

---

From: Matthew Ford <[email-masked]>
Date: Thu, 8 Jul 2010 09:50:08 +0100

> Thanks for the information. This is definitely interesting, and there are plenty of opportunities to test -- on dual stack networks, on ipv6-only, on ipv6-only + nat64, actual capabilities of peers…

I have been running the code developed by Martin Defêche and presented by Eric Vyncke at IETF76 in Hiroshima [1] for a while now. I plan to put some results and regularly updated longitudinal analysis online soon.

In the meantime, I'm seeing ~2.5% of peers with some form of IPv6 connectivity. Of those, ~8.5% are 6to4, ~91% are Teredo, and ~0.5% native.

Mat

[1] http://www.ietf.org/proceedings/76/slides/v6ops-9.pdf

---

From: Matthew Ford <[email-masked]>
Date: Thu, 8 Jul 2010 15:11:04 +0100

On 8 Jul 2010, at 09:50, Matthew Ford wrote:

> 
> In the meantime, I'm seeing ~2.5% of peers with some form of IPv6 connectivity.

Of course, what I meant to write was 0.25%....

Mat

---

From: Ari Keranen <[email-masked]>
Date: Thu, 08 Jul 2010 18:30:46 +0300

Hi Marcelo,

Thanks for the comments! We made some clarifications to the draft 
accordingly and will soon post a new revision. I can also try to clarify 
the fragmentation issue below.

On 07/07/2010 12:11 PM, Jari Arkko wrote:
 > On 07/06/2010 12:36 PM, marcelo bagnulo braun wrote:

Essentially the problem was that if DF bit is not set, fragmentation 
header is always added even if the packet was not a fragment. One of our 
firewalls did not support IPv6 fragment header, so every packet with it 
(i.e., every IPv4 packet with DF bit off) was simply dropped. Thus we 
ended up disabling that feature.

I think it would make sense to avoid the frag header if possible since 
even a fully IPv6 capable firewall is somewhat likely to drop fragments 
to avoid fragment attacks. Also, having a fragment header but no 
fragments looks suspicious, to say the least. That said, if there is no 
better way to convey the DF bit state, updating firewall IPv6 code 
(luckily, there isn't much of that yet :) supporting such "fake 
fragments", once standardized, should not be that hard.

Cheers,
Ari

---

From: Simon Perreault <[email-masked]>
Date: Thu, 08 Jul 2010 11:51:15 -0400

> fragments", once standardized, should not be that hard.

Looking at the relevant text:

   However, when the IPv4 sender does not set the Don't Fragment (DF)
   bit, the translator MUST ensure that the packet does not exceed the
   path MTU on the IPv6 side.  This is done by fragmenting the IPv4
   packet so that it fits in 1280-byte IPv6 packets, since that is the
   minimum IPv6 MTU.  Also, when the IPv4 sender does not set the DF bit
   the translator MUST always include an IPv6 fragment header to
   indicate that the sender allows fragmentation.

IPv6 packets produced as a result of this will never exceed 1280 bytes.
Either there will be multiple fragments or a single one. In case there
is a single one, why do we need to indicate that "the sender allows
fragmentation"? It is never going to be fragmented again since it is
already below 1280 bytes.

Simon
-- 
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server        --> http://numb.viagenie.ca
vCard 4.0               --> http://www.vcarddav.org

---

From: Cameron Byrne <[email-masked]>
Date: Thu, 8 Jul 2010 09:00:49 -0700

On Thu, Jul 8, 2010 at 8:30 AM, Ari Keranen <[email-masked]> wrote:
> accordingly and will soon post a new revision. I can also try to clarify the
> fragmentation issue below.
>
> Essentially the problem was that if DF bit is not set, fragmentation header
> is always added even if the packet was not a fragment. One of our firewalls
> did not support IPv6 fragment header, so every packet with it (i.e., every
> IPv4 packet with DF bit off) was simply dropped. Thus we ended up disabling
> that feature.
>
> I think it would make sense to avoid the frag header if possible since even
> a fully IPv6 capable firewall is somewhat likely to drop fragments to avoid
> fragment attacks. Also, having a fragment header but no fragments looks
> suspicious, to say the least. That said, if there is no better way to convey
> the DF bit state, updating firewall IPv6 code (luckily, there isn't much of
> that yet :) supporting such "fake fragments", once standardized, should not
> be that hard.
>

Agreed.  I have seen  issues in a few places, including Fedora

https://bugzilla.redhat.com/show_bug.cgi?id=547602

And just this week a major vendor confirmed that the fragment header
caused an MTU issue within their ASIC and suggested that I have the
NAT-PT box adjust all the MSS for all flows to be low enough to
accommodate their ASIC fragment header issue ...

Cameron

---

From: Ari Keranen <[email-masked]>
Date: Thu, 08 Jul 2010 19:13:57 +0300

> already below 1280 bytes.

The packet could be translated back to IPv4 before reaching the 
destination. Corner case? Perhaps.

Cheers,
Ari

---

From: Simon Perreault <[email-masked]>
Date: Thu, 08 Jul 2010 12:47:58 -0400

On 2010-07-08 12:13, Ari Keranen wrote:
> destination.

This use case should be out of scope. Packets that start from IPvX and
end up also on IPvX should not go through a protocol translator.

Simon

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 8 Jul 2010 11:40:42 -0700

> Behalf Of Ari Keranen
> Sent: Thursday, July 08, 2010 8:31 AM
> To: marcelo bagnulo braun
> Cc: Andrew Sullivan; Behave WG; Jari Arkko
..............^^^^^^^^^^^^^^^^^

Such use of fragmentation header is already standardized in both
RFC1883 (original IPv6 specification, published 1995) and RFC2460
(current IPv6 specification, published 1998).

Here is the text from Section 5 of RFC2460,
<http://tools.ietf.org/html/rfc2460#section-5>,

   In response to an IPv6 packet that is sent to an IPv4 destination
   (i.e., a packet that undergoes translation from IPv6 to IPv4), the
   originating IPv6 node may receive an ICMP Packet Too Big message
   reporting a Next-Hop MTU less than 1280.  In that case, the IPv6 node
   is not required to reduce the size of subsequent packets to less than
   1280, but must include a Fragment header in those packets so that the
   IPv6-to-IPv4 translating router can obtain a suitable Identification
   value to use in resulting IPv4 fragments.  Note that this means the
   payload may have to be reduced to 1232 octets (1280 minus 40 for the
   IPv6 header and 8 for the Fragment header), and smaller still if
   additional extension headers are used.

(RFC1883's text is exactly the same except referred to the 
then-standard IPv6 minimum MTU of 576.)

-d

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 9 Jul 2010 00:04:18 +0200

> accommodate their ASIC fragment header issue ...

Note that after a bunch of discussion we came to the conclusion that there shouldn't be any MSS adjustment in NAT64.

---

From: Ari Keranen <[email-masked]>
Date: Fri, 09 Jul 2010 09:28:52 +0300

> end up also on IPvX should not go through a protocol translator.

I don't fully agree on that. I could see this happening in a scenario 
where the backbone is IPv6-only but the end-hosts' networks are both IPv4.

Cheers,
Ari

---

From: Ari Keranen <[email-masked]>
Date: Fri, 09 Jul 2010 09:30:02 +0300

>> fragments", once standardized, should not be that hard.

Good point. So now all it takes is to file bug reports..

Cheers,
Ari

---

From: Ari Keranen <[email-masked]>
Date: Fri, 09 Jul 2010 11:01:58 +0300

> https://bugzilla.redhat.com/show_bug.cgi?id=547602

Great that this bug is already reported! Hopefully it is also fixed 
soon. Although, I wonder if it should be reported to some other bug 
tracker too since it seems to be an ip6tables issue.

> accommodate their ASIC fragment header issue ...

Yeah, fragmentation is a pain. I've also seen too many boxes with really 
unexpected behavior when fragmentation kicks in.

Cheers,
Ari