Subject: [v4v6interim] You have been dugg!

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 7 Oct 2008 15:46:55 +0200

http://digg.com/tech_news/IETF_working_on_making_IPv6_and_IPv4_talk_to_each_other
_______________________________________________
v4v6interim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v4v6interim

---

From: Ed Jankiewicz <[email-masked]>
Date: Tue, 07 Oct 2008 11:45:49 -0400

I'm sure the folks on Digg will boldly go where no IETFer has gone 
before and come up with an instant solution in 25 words or 
less...immediately reviewed and dismissed...saves a lot of time and 
brainpower, and avoids the overhead of publishing the Solution X RFC 
followed by the Solution X is Evil RFC followed by the "Solution X is 
Evil RFC" is Evil RFC followed by...

my favorite - "They didn't figure that out already?"

On the other hand, you did a great job of summarizing a lot of 
discussion (over years) and a dozen drafts (currently being circulated) 
into a one-page summary in nearly layman's terms (at least network 
hobbyist level).  Thanks.

FYI, while I am an advocate for (eventually) solving the v4 client to v6 
server scenario, I agree that the priority should be on the v6 client to 
v4 Internet solution, and we don't want to hold up that solution for an 
integrated two-way translator. 

Ed J.

-- 
Ed Jankiewicz - SRI International
Fort Monmouth Branch Office - IPv6 Research 
Supporting DISA Standards Engineering Branch
732-389-1003 or  [email-masked]

---

From: Fred Baker <[email-masked]>
Date: Tue, 7 Oct 2008 10:26:23 -0700

> http://digg.com/tech_news/IETF_working_on_making_IPv6_and_IPv4_talk_to_each_other

Thanks. Good article. I think the title is amusing; one would think  
that there was no prior work on making IPv4 and IPv6 talk with each  
other. But as you point out, there of course has been.

Let me comment on your comments re IVI:

> Finally, there is a solution named IVI (IV and VI, get it?) which  
> updates NAT-PT but also creates a direct, SIIT-like mapping between  
> certain IPv4 and IPv6 addresses. Unfortunately, this requires some  
> un-IPv6 like configuration on the IPv6 side, so it's not obvious to  
> me how this is useful. But apparently, IVI has been in use in China  
> for two years.

What does it mean to be "IPv6-like"?

Looking through RFCs 1884 (2.4.4), 2373 (2.5.4), 3513 (2.5.5), 4291  
(2.5.5), and 2765 (2.1), and additionally looking at NAT64 (section  
5.1), the addressing architecture has always had in it some form of  
address that embeds IPv4 into an IPv6 address. None of those memos  
have discussed how that was allocated or how a host was supposed to  
get them; the one thing that has been perfectly clear throughout is  
that they were not allocated by SLACK - they would have to be manually  
assigned or automatically assign via the mechanisms we use for IPv4  
address allocation, probably using DHCP to communicate them to the  
host and either Dynamic DNS or manual DNS management to associate them  
with names.

The one point of disagreement that I have had with Marcello's  
Pref64::/96 characterization is that it does something that RFC 4291  
says to not do. If we have a prefix whose left-most bits are not 000,  
we are supposed to reserve the right-most 64 bits for host identifier  
and contain the routing prefix in the left-most 64 bits; RFC 4291  
makes that clear in section 2.5.1, 2.5.4, 2.5.6, and 2.5.7. As such,  
neglecting the question of using the 0::ffff:a.b.c.d, 0::0:a.b.c.d, or  
0::ffff:0:a.b.c.d forms, if I have a prefix assigned by the network  
operator, the address architecture says that I would have to treat all  
Pref64::a.b.c.d routes as host routes. Tell me that this is not what  
you're hoping for in an IPv6 address?

What CERNET has done is define an address that maps to RFC 4291's  
architecture, allows them to (within that architecture) subnet IPv4- 
mapped addresses in the IPv6 domain, and use the mapping effectively  
in routing. If there is anything that I would hope was IPv6-like, it  
would have those characteristics.

All you do is crab; you don't like it, but you don't give a technical  
reason to not like it. What's your point?
_______________________________________________
v4v6interim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v4v6interim

---

From: Rémi Després <[email-masked]>
Date: Wed, 08 Oct 2008 09:12:54 +0200

> http://digg.com/tech_news/IETF_working_on_making_IPv6_and_IPv4_talk_to_each_other 

Very clear article, and very nice reading :-).

It would have been more accurate, though, if the A+P and SAM approaches
would at least have been listed. (Having NAT64, DS Lite and IVI as the
complete list of solutions discussed "to make the IPv4 world talk to the
(future) IPv6 world" is missing something.)

Worth being remembered: SAM has more potential than other solutions for
IPv4-only clients to reach an IPv6 capable server that only has a shared 
IPv4 address (with a restricted port range, accessible via tunnels).

In particular, in draft-despres-SAM-v4v6coexistenceScenarios-00,
scenario C is as follows (simplified to have encapsulation in IPv6 only,
and complemented to show on it supports connections both ways).

+------+                                    +--------+   Global
| SAM  |           +---------+              |  SAM   |  Internet
| host |--site v6--| SAM CPE |-- ISP v6 ----| ISP GW |<--- v4 -->
+------+           +---------+              +--------+

   SAM <--- v4/v6 -->SAM1 SAM2<---- v4/v6 ---> SAM <----- v4 ---->
     :                    :                      :
     '- Port restricted   '- Stateless CPE       '--- Stateless GW
           socket interface

         <---- transparency to global v4 packets ----->
              (outgoing AND incoming connections)

Regards,

RD

---

From: "Turchanyi Geza" <[email-masked]>
Date: Fri, 10 Oct 2008 09:09:05 +0200

Hello,

Well, SAM is an interesting idea.

HOWEVER: if we can implement new software (almost)everywhere, than why
not to use IPv6 everywhere?

I missed the point: what can be kept unchanged in the SAM scenario?

Thanks,

Geza

---

From: Rémi Després <[email-masked]>
Date: Fri, 10 Oct 2008 14:39:31 +0200

> not to use IPv6 everywhere?

Two points.
- For SAM to be useful, it doesn't need at all to be available 
everywhere, or even "almost" everywhere: if an ISP has it, its clients 
that also have it can take advantage of its properties (deployment is 
incremental).
- In scenario C, although the customer site has no global IPv4 address 
reserved for it, its SAM hosts are reachable, without NAT traversal, by 
IPv4-only remote clients.

> I missed the point: what can be kept unchanged in the SAM scenario?
In scenario C below, an IPv4 datagram exchanged between the SAM host and 
any remote host that requires the connection to be IPv4 is unchanged 
end-to end. Both source and destination addresses and ports of the 
datagram, and its protocol, are received as sent (5-tuple preservation). 
The IPv4 only host ignores that encapsulation in IPv6 has taken place 
somewhere.

5-tuples being neither restricted nor modified E2E, the solution is more 
general than those that impose NAT traversal. In particular, it ensures 
compatibility with SCTP and with any other transport protocol that may 
be useful in the future.

Regards,

RD

---

From: Randy Bush <[email-masked]>
Date: Fri, 10 Oct 2008 07:45:33 -0700

> HOWEVER: if we can implement new software (almost)everywhere

we have these pesky things called "customers."

randy

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 10 Oct 2008 08:33:15 -0700

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Turchanyi Geza
> Sent: Friday, October 10, 2008 12:09 AM
> To: Rémi Després
> Cc: [email-masked]
> Subject: Re: [v4v6interim] You have been dugg!
> 
> Hello,
> 

Because there is no content on IPv6 yet.  Visit
http://www.alexa.com/site/ds/top_sites?ts_mode=global&lang=none and
do AAAA queries against those websites.

-d

---

From: Lars Eggert <[email-masked]>
Date: Sat, 11 Oct 2008 10:54:37 +0200

> do AAAA queries against those websites.

Or go to http://utility.nokia.net/~lars/meter/ipv6.html, which does  
this for you :-)

Lars

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Sat, 11 Oct 2008 14:02:22 +0200

Interesting and disappointing at the same time. Is there any chance to get another version of the same statistics where not only www.example.com will be queried but also www6.example.com ipv6.example.com (this is of course a vastly different metric but could also be useful).

To come back to Dan's email, is there a way to get alexa statistics weigthed by the %-age of global Internet traffic? I.e. if the first 10 sites were on IPv6, how much Internet traffic would be over IPv6? 

And if you put the web server sites IPv6 readiness (cfr Lars' email) and the client IPv6 readiness (cfr discussion on v6ops -- roughly 6-10% of clients can access IP6 only site), this is a factual confirmation that the content site is lagging... (which is of course easier to fix than the client site).

Regards

-éric 

> [mailto:[email-masked]] On Behalf Of Lars Eggert
> Sent: samedi 11 octobre 2008 10:55
> To: Dan Wing (dwing)
> Cc: [email-masked]
> http://www.alexa.com/site/ds/top_sites?ts_mode=global&lang=non
> e and do 
> > AAAA queries against those websites.
> 
> Or go to http://utility.nokia.net/~lars/meter/ipv6.html, 
> which does this for you :-)
> 
> Lars

---

From: Lars Eggert <[email-masked]>
Date: Sat, 11 Oct 2008 18:13:28 +0300

On 2008-10-11, at 15:02, ext Eric Vyncke (evyncke) wrote:
> Interesting and disappointing at the same time. Is there any chance  
> to get another version of the same statistics where not only www.example.com 
>  will be queried but also www6.example.com ipv6.example.com (this is  
> of course a vastly different metric but could also be useful).

Good suggestion. I'll add that when I have a minute, I need to fix a  
bug related to DKIM tracking anyway. Any other prefixes that www6 and  
ipv6 that I should check?

(The spike you see in the history plot around August was due to a  
similar change - I started doing lookups for www.example.com in  
addition to just example.com.)

Lars

---

From: Lars Eggert <[email-masked]>
Date: Sat, 11 Oct 2008 18:14:47 +0300

On 2008-10-11, at 15:02, ext Eric Vyncke (evyncke) wrote:
> To come back to Dan's email, is there a way to get alexa statistics  
> weigthed by the %-age of global Internet traffic? I.e. if the first  
> 10 sites were on IPv6, how much Internet traffic would be over IPv6?

Not through Alexa alone. If anyone has pointers to data that I could  
correlate the stats with, that'd be great.

(Or, ideally, a willing operator would share their aggregate DNS  
lookup stats & traffic loads...)

Lars

---

From: "Dan Wing" <[email-masked]>
Date: Sat, 11 Oct 2008 08:48:43 -0700

> From: Lars Eggert [mailto:[email-masked]] 
> Sent: Saturday, October 11, 2008 8:13 AM
> To: ext Eric Vyncke (evyncke)
> Cc: Dan Wing (dwing); [email-masked]
> bug related to DKIM tracking anyway. Any other prefixes that 
> www6 and ipv6 that I should check?

Are users expected to know of, and use those URLs?  They can't be 
forwarded in email or IM to someone running IPv4-only -- which 
is the ultimate 'referral' (so often talked about abstractly 
by IETFers).

-d

---

From: "Dan Wing" <[email-masked]>
Date: Sat, 11 Oct 2008 08:48:58 -0700

> Sent: Saturday, October 11, 2008 1:55 AM
> To: ext Dan Wing
> Cc: 'Turchanyi Geza'; "'Rémi Després'"; [email-masked]

Thanks.
-d

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Sat, 11 Oct 2008 17:52:28 +0200

> Are users expected to know of, and use those URLs?  They 
> can't be forwarded in email or IM to someone running 
> IPv4-only -- which is the ultimate 'referral' (so often 
> talked about abstractly by IETFers).

Dan,

No of course, but, I would be really nice if Lars could extend his page with both statistics for pure dual-stack www.example.com and with statistics for the bare minimum www6.example.com & ipv6.example.com. This would give us useful information (at least from my point of view).

Regards

-éric

---

From: Lars Eggert <[email-masked]>
Date: Sun, 12 Oct 2008 01:06:33 +0300

I made these changes. The new dataset will be gathered 1AM PST.

Lars

On 2008-10-11, at 18:13, ext Lars Eggert wrote:
>>  will be queried but also www6.example.com ipv6.example.com (this  
>> is of course a vastly different metric but could also be useful).
>
> bug related to DKIM tracking anyway. Any other prefixes that www6  
> and ipv6 that I should check?
>

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 13 Oct 2008 14:42:16 +0200

> What does it mean to be "IPv6-like"?

That everything happens mostly automatic and is easy otherwise. For  
instance, in IPv4 you have to think about how big each subnet is. In  
IPv6 you don't.

> says to not do. If we have a prefix whose left-most bits are not  
> 000, we are supposed to reserve the right-most 64 bits for host  
> identifier

Yes, I know. What I don't know is why this text was put in the RFC, so  
far nobody has been able (or willing) to tell me that.

> As such, neglecting the question of using the 0::ffff:a.b.c.d,  
> 0::0:a.b.c.d, or 0::ffff:0:a.b.c.d forms, if I have a prefix  
> assigned by the network operator, the address architecture says that  
> I would have to treat all Pref64::a.b.c.d routes as host routes.  
> Tell me that this is not what you're hoping for in an IPv6 address?

Not entirely sure what you're trying to say. But obviously we can  
specify the behavior that we want in a new specification so I don't  
know why it would matter.

> All you do is crab; you don't like it, but you don't give a  
> technical reason to not like it. What's your point?

The IVI mapping means that at the very least a special subnet has to  
be created for every IPv4-reachable host. The suggestion of having  
non-/64 subnets and DHCPv6 is very problematic because DHCPv6 doesn't  
know about subnet prefix lengths.

The situation where a static mapping is set up means that the  
configuration can be limited to the translation box, this simply makes  
much more sense on every level.
_______________________________________________
v4v6interim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v4v6interim

---

From: Fred Baker <[email-masked]>
Date: Mon, 13 Oct 2008 15:23:26 -0700

> instance, in IPv4 you have to think about how big each subnet is. In  

I disagree. The discussion of /48 vs /56 vs /60 vs /64 comes to mind.  
And btw this is about a IPv4 address, like NAT64 etc are. You make  
relatively positive statements about the other options and dump on one  
that has the same strengths and weaknesses.

> non-/64 subnets and DHCPv6 is very problematic because DHCPv6  
> doesn't know about subnet prefix lengths.

we have a way to assign a prefix using DHCP. You're telling me it  
doesn't know the prefix length? If so, it's broken. I haven't read  
that spec; remind me which it is?

And yes, regardless of the address format used - even SLACK, for that  
matter - one has to either inject a host route into routing or inject  
a prefix into routing. That's how routing works. The only way we can  
avoid that is to put every mapped-address host on a LAN shared with  
the translator. Bzzt. That doesn't scale.

> configuration can be limited to the translation box, this simply  
> makes much more sense on every level.

Actually, not so. And this differs from NAT64, which you spoke  
positively about, in what way?
_______________________________________________
v4v6interim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v4v6interim

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 13 Oct 2008 18:33:25 -0400

I haven't had the time to catch up to these emails and get a proper
perspective.  But just a quick comment that DHCPv6 is not broken if
DHCPv6 responses from the server to the client do not include prefix
length - that's by design of the IPv6 architecture where the router on
the network is responsible for doling out the prefix length to the
clients and NOT the DHCPv6 server.

Hemant 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Fred Baker (fred)
Sent: Monday, October 13, 2008 6:23 PM
To: Iljitsch van Beijnum
Cc: [email-masked]
Subject: Re: [v4v6interim] You have been dugg!

we have a way to assign a prefix using DHCP. You're telling me it
doesn't know the prefix length? If so, it's broken. I haven't read that
spec; remind me which it is?

And yes, regardless of the address format used - even SLACK, for that
matter - one has to either inject a host route into routing or inject a
prefix into routing. That's how routing works. The only way we can avoid
that is to put every mapped-address host on a LAN shared with the
translator. Bzzt. That doesn't scale.

---

From: Fred Baker <[email-masked]>
Date: Mon, 13 Oct 2008 15:47:58 -0700

um, hold on. two uses.

DHCPv6 is used to assign host addresses to host interfaces. They only  
have one prefix length: /128.

DHCPv6 is also used to assign a prefix to the CPE router in a home.  
the addcon draft, in large part, is saying that these are not always  
(and perhaps should never be) /64. Please tell me that we can assign  
a /60, a /56, or a /48 to a home if we want to.

On Oct 13, 2008, at 3:33 PM, Hemant Singh (shemant) wrote:

>> makes

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 13 Oct 2008 18:55:28 -0400

If the DHCPv6 PD option (RFC3633) is used to assign a prefix to the CPE
router in a home, then sure, since the PD option format includes a
prefix length, by all means, any ISP can assign the CPE router a prefix
of length the ISP so desires by their network design.  I was talking
about DHCPv6 without the PD option where DHCPv6 address assignment does
not include a prefix length. Doling out a PD option to a router is
different from DHCPv6 address assignment. 

Hemant 

-----Original Message-----
From: Fred Baker (fred) 
Sent: Monday, October 13, 2008 6:48 PM
To: Hemant Singh (shemant)
Cc: Iljitsch van Beijnum; [email-masked]
Subject: Re: [v4v6interim] You have been dugg!

um, hold on. two uses.

DHCPv6 is also used to assign a prefix to the CPE router in a home.  
the addcon draft, in large part, is saying that these are not always
(and perhaps should never be) /64. Please tell me that we can assign a
/60, a /56, or a /48 to a home if we want to.

> [mailto:[email-masked]
> ]

---

From: Ralph Droms <[email-masked]>
Date: Mon, 13 Oct 2008 18:55:45 -0400

Fred - yes, PD prefixes include the prefix length.

Arguing pedantically (reverting to my previous life for a minute) with  
your first statement, IMO an address, by itself, doesn't have a prefix  
length.  The prefix it matches for, e.g., routing may have a prefix  
length, but the address doesn't have a prefix length at all...

- Ralph

On Oct 13, 2008, at Oct 13, 2008,6:47 PM, Fred Baker wrote:

> um, hold on. two uses.
>
> DHCPv6 is used to assign host addresses to host interfaces. They  
> only have one prefix length: /128.
>

---

From: "TJ" <[email-masked]>
Date: Mon, 13 Oct 2008 18:58:06 -0400

>I disagree. The discussion of /48 vs /56 vs /60 vs /64 comes to mind.

That is a discussion more about block allocation (aka prefix delegation) vs
a single subnet's size, yes?

/TJ

---

From: Fred Baker <[email-masked]>
Date: Mon, 13 Oct 2008 15:59:35 -0700

On Oct 13, 2008, at 3:55 PM, Hemant Singh (shemant) wrote:

> Doling out a PD option to a router is

I'm sure we're talking about routers here.
_______________________________________________
v4v6interim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v4v6interim

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 16 Oct 2008 10:17:03 +0200

On 14 okt 2008, at 0:23, Fred Baker wrote:

>> instance, in IPv4 you have to think about how big each subnet is.  
>> In IPv6 you don't.

> I disagree. The discussion of /48 vs /56 vs /60 vs /64 comes to mind.

Which was a bad idea; one prefix length for everyone is preferable.

But it's also irrelevant to the discussion at hand, what I was talking  
about is that all IPv6 subnets are (should be) /64, while with IPv4  
you need to think about how many hosts will have to fit in a subnet  
and size it accordingly.

> that spec; remind me which it is?

Are you saying that you want to use DHCPv6 prefix delegation to give  
out prefixes to IPv6 hosts that are reachable from the IPv4 side  
through IVI? Not sure if that makes everything easier. One of the  
issues with PD is to get the routers to know what's going on, and the  
host would still have to fill in the correct lower bits.

With DHCPv6 address assignment you just get the address, with no  
knowledge about the subnet. For the host this is probably not a big  
deal (in the IVI case with presumably no other hosts on the same  
subnet) but the routers need to know the subnet so they know how to  
send packets to the host in question.

> Actually, not so.

How does it make sense to have to touch more boxes?

Or, what benefit is there that outweighs this downside?

> And this differs from NAT64, which you spoke positively about, in  
> what way?

NAT64 doesn't impose addressing requirements on the IPv6 side.
_______________________________________________
v4v6interim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v4v6interim

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 16 Oct 2008 10:25:16 +0200

> a /60, a /56, or a /48 to a home if we want to.

Of course. Have a look at your own products, it works just fine.

>> But just a quick comment that DHCPv6 is not broken if

It would be great if we could classify this as a mistake (much like  
the whole business with the reverse DNS mapping for IPv6  
with .int/.arpa) and fix this, but unfortunately adding a prefix  
length will only help a little to make all of this stuff better.
_______________________________________________
v4v6interim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v4v6interim