headers
Fred Baker | 1 May 2006 18:15
Picon
Favicon

Re: IETF Meeting Survey

Folks:

we have been asked for our opinions on the recent IETF meeting. Would  
you kindly take a look at the survey?

On May 1, 2006, at 8:24 AM, Ray Pelletier wrote:
> All;
> It has been suggested that if I really wanted to get feedback on  
> the Meeting Survey (and I do)  I should have it forwarded by the WG  
> Chairs to the working groups - so this is a request that you ask  
> members of the working groups to complete a short survey that  
> focuses primarily, but not exclusively, on their meeting experience  
> in Dallas.
> I truly want the info to make the changes members of the community  
> want, if possible and greatly appreciate your assistance in this  
> regard.
>
> Those interested in taking the survey can find it at:
> http://www.surveymonkey.com/s.asp?u=649182049947
>
> Thanks
> Ray Pelletier
> IETF Admininstrative Director
>
Permalink | Reply | 0 comments |
headers
Tim Chown | 3 May 2006 12:42
Picon
Favicon

European IPv6 Convergence Event, Vienna, 1st/2nd June

Hi,

I'm a bit nervous about sending what may be considered spam to this
list, but I feel this is probably the European Commission's biggest
IPv6 event of the year, and it has a deployment focus on convergence
of services on IPv6, so is relevent to what people are discussing
in v6ops.

It's in Vienna and free to register/attend, with speakers from all
over the world.

People on list particularly in Europe may be interested in coming
along, if so then there's info and registration details here:

        http://www.ipv6-convergence-vienna.net/

Cheers,

--
Tim/::1
Permalink | Reply | 3 comments |
headers
David Malone | 3 May 2006 17:25
Picon
Picon
Favicon

Re: European IPv6 Convergence Event, Vienna, 1st/2nd June

On Wed, May 03, 2006 at 11:42:40AM +0100, Tim Chown wrote:
> It's in Vienna and free to register/attend, with speakers from all
> over the world.

I also note that the conference is being streamed, so if you can't
make it to Vienna you're not out of luck.

	David.
Permalink | Reply | 2 comments |
headers
Joe Abley | 7 May 2006 21:24

Re: European IPv6 Convergence Event, Vienna, 1st/2nd June


On 3-May-2006, at 18:25 , David Malone wrote:

> On Wed, May 03, 2006 at 11:42:40AM +0100, Tim Chown wrote:
>> It's in Vienna and free to register/attend, with speakers from all
>> over the world.
>
> I also note that the conference is being streamed, so if you can't
> make it to Vienna you're not out of luck.

Is it being streamed over IPv6?
Permalink | Reply | 1 comment |
headers
Tim Chown | 8 May 2006 12:18
Picon
Favicon

Re: European IPv6 Convergence Event, Vienna, 1st/2nd June

On Sun, May 07, 2006 at 10:24:41PM +0300, Joe Abley wrote:
> 
> On 3-May-2006, at 18:25 , David Malone wrote:
> 
> >On Wed, May 03, 2006 at 11:42:40AM +0100, Tim Chown wrote:
> >>It's in Vienna and free to register/attend, with speakers from all
> >>over the world.
> >
> >I also note that the conference is being streamed, so if you can't
> >make it to Vienna you're not out of luck.
> 
> Is it being streamed over IPv6?

At present I believe the Austria Telekom streaming service is v4 only but 
a v6 facility is being investigated.

--

-- 
Tim/::1
Permalink | Reply | 0 comments |
headers
Internet | 9 May 2006 00:50
Picon
Favicon

I-D ACTION:draft-ietf-v6ops-ent-analysis-05.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		: IPv6 Enterprise Network Analysis
	Author(s)	: J. Bound, et al.
	Filename	: draft-ietf-v6ops-ent-analysis-05.txt
	Pages		: 38
	Date		: 2006-5-8
	
This document analyzes the transition to IPv6 in enterprise
 networks.  These networks are characterized as a network that has
 multiple internal links, one or more router connections, to one or
 more Providers, and is managed by a network operations entity.  The
 analysis will focus on a base set of transition notational networks
 and requirements expanded from a previous Enterprise Scenarios
 document. Discussion is provided on a focused set of transition
 analysis required for the enterprise to transition to IPv6,
 assuming a Dual-IP layer (IPv4 and IPv6) network and node
 environment, within the enterprise.  Then a set of transition
 mechanisms are recommended for each notational network.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ent-analysis-05.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@... with the word unsubscribe in the body of the
message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Pekka Savola | 9 May 2006 16:27
Picon

RFC3484 problem: scoping with site-locals/ULAs

Hi,

I was alerted to a practical deployment problem. As a result Linux 
glibc has started prefering IPv4 by default... so, I believe we need 
to find a better solution.

1) v6 site-local address selection problems

A site has deployed IPv6 site-local addresses (alongside with NATed 
v4).  They do not have global IPv6 reachability yet, but want to test 
IPv6 alongside IPv4 internally.

As a result, RFC 3484 address selection breaks: when trying to connect 
to a hostname with a public IPv4 and IPv6 address, the host will first 
try v6 fails (incurring about 3 min TCP timeout if ICMP error is not 
sent), and after that connects to the v4 address.

I.e., 'prefer matching scope' has v6 globals and site-locals, while v4 
has globals and private v4 addresses, and v6 wins, with bad results.

An easy fix could be that v4 is preferable to v6 if both have 
mismatching scope as v4 is likely to be NATed while v6 isn't.

Has anyone else run into this problem?  Is there something I'm 
missing?  What has been the implementation (or deployment) approach 
here?

(I don't believe using RFC 4191 to advertise only the site-local 
prefix instead of a default route is a feasible solution here. 
Likewise, requiring that routers will always send back an ICMP error
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rémi Denis-Courmont | 9 May 2006 17:32

Re: RFC3484 problem: scoping with site-locals/ULAs

Le Mardi 9 Mai 2006 17:27, Pekka Savola a écrit :
> 1) v6 site-local address selection problems

I assume you refer to the deprecated but Linux kernel-supported 
site-local fec0::/12 address space (not sure if it is /12 - but 
anyway).

> A site has deployed IPv6 site-local addresses (alongside with NATed
> v4).  They do not have global IPv6 reachability yet, but want to test
> IPv6 alongside IPv4 internally.

> As a result, RFC 3484 address selection breaks: when trying to
> connect to a hostname with a public IPv4 and IPv6 address, the host
> will first try v6 fails (incurring about 3 min TCP timeout if ICMP
> error is not sent), and after that connects to the v4 address.

I am pretty sure it used to work “properly”... when trying to connect() 
to some public IPv6 address while the host only had link-local and 
site-local addresses, the stack would immediatly (non-blocking) address 
unreachable. Then software using the getaddrinfo() paradigm would 
fallback to IPv4 without the user noticing any delay. But then indeed, 
it seems to be now broken.

> 2) v6 ULA address selection problems
>
> Deploying ULAs doesn't help here, it just makes the problem worse as
> you couldn't even use the 'matching scope' tweak.

Yes, I definitely have had these issues. Since ULA have global scope, 
there is no way to detect the issue there.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eliot Lear | 9 May 2006 17:49
Picon
Favicon

Re: RFC3484 problem: scoping with site-locals/ULAs

Pekka,

Where is DNS in this picture?  How did you get the v6 address that
didn't work?

Eliot

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Permalink | Reply | 0 comments |
headers
David Woodhouse | 9 May 2006 16:58
Favicon

Re: RFC3484 problem: scoping with site-locals/ULAs

On Tue, 2006-05-09 at 17:27 +0300, Pekka Savola wrote:
> Likewise, requiring that routers will always send back an ICMP error 
> and the host gets it and honors it seems unfeasible in general.)

That's the ideal case, of course -- but there is unfortunately still
software out there (and, more to the point, in _here_) which will just
use the first result from getaddrinfo() and not fall back to the others
even if it does get an immediate failure.

This _used_ to work on Linux systems until recently. This is because
glibc will use UDP connect() and getsockname() to determine (src, dest)
address pairs, and in the past the connect() would fail if the host had
only site-local addresses and was asked to connect to a global IPv6
address. That behaviour of the kernel has now changed, and the dummy
connect() succeeds.

Glibc's RFC3484 support is described at
http://people.redhat.com/drepper/linux-rfc3484.html

I think it would suffice to add a label for fec0::/16 in the default
table, so that in the case where we choose between RFC1918->Global IPv4
and Site-local-≥Global IPv6, the former is ordered first by virtue of
Rule 5 -- because the labels match on the IPv4, but not on the IPv6.

That's the behaviour we always _did_ have under Linux, although
seemingly by coincidence.

--

-- 
dwmw2
(Continue reading)

Permalink | Reply | 0 comments |

Gmane