Subject: Re: I-D Action:draft-kawamura-ipv6-text-representation-01.txt

From: Brian E Carpenter <[email-masked]>
Date: Wed, 22 Apr 2009 14:15:29 +1200

As I understand it, this draft defines a canonical form
of address representation and recommends that it be used
to minimise human confusion.

That isn't a bad idea, but IMHO we need a clear statement
that humans and algorithms SHOULD generate this format,
and that all implementations MUST accept any legitimate
RFC4291 format.

   Brian

---

From: Seiichi Kawamura <[email-masked]>
Date: Wed, 22 Apr 2009 12:33:51 +0900

Hi Brian, All

Thanks for the comment!

> to minimise human confusion.

yes. exactly.

> and that all implementations MUST accept any legitimate

That was sort of my intention with the phrase
"The recommendation in this document is one that,
complies fully with RFC 4291..." (Section 4.)
but maybe I was a bit vague.

It would be nice to hear more thoughts on the draft.

Thanks,
Seiichi

---

From: Jeroen Massar <[email-masked]>
Date: Wed, 22 Apr 2009 15:43:20 +0200

> and that all implementations MUST accept any legitimate

What I tend to do in my programs is accept any and then "rewrite" the
address, generally just using getaddrinfo(), then only using the data
returned by getaddrinfo; representation to the user can then be done by
getnameinfo(). This way one always(*) has the same format. It is a bit
'bad' that one can't store eg /64 inside that structure, now one always
have to keep it separate.

Greets,
 Jeroen

* = unless the function calls do random changes at output time but from
what I have seen all platforms do lowercase hex fully compressed hex output.

---

From: "HUANG, ZHIHUI (JERRY), ATTLABS" <[email-masked]>
Date: Wed, 22 Apr 2009 11:05:48 -0400

Seiichi, 
  Your draft (section 2.2, near bottom of page 5) references RFC4291
section 2.2 on using '::' "to compress leading or trailing zeros in an
address". The example followed in your text doesn't really have either
leading or trailing zeros (2001:db8::aaaa:0:0:1, and
2001:db8:0:0:aaaa::1). My reading of RFC4291 text above points to
compressing, for example, the IPv6 loopback address to '::1' (leading
zeros), but doesn't say about how to deal with multiple "compressible"
chunks of zeros. The same paragraph in RFC4291 also says that  "The '::'
can only appear once in an address". Perhaps that's a better reference
for your intention here where one is forced to and has the flexibility
to choose only one of the compressible zero strings.

  Section 4.1,  should we say "Handling Leading Zeros in a 16 bit Field"
instead of "Handling Leading Zeros" which might also mean "leading zeros
of an IPv6 address".

  Section 4.2.1 and 4.2.3, could we be more explicit and combine these
two to say "Use '::' to replace/compress the longest string of zero
chunks in an address, where there are two such strings of the same
length, the first string is replaced.".

Thanks,
Jerry
--
Jerry Huang, AT&T Labs, +1 630 810 7679
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Seiichi Kawamura
Sent: Tuesday, April 21, 2009 10:34 PM
To: Brian E Carpenter
Cc: [email-masked]; IPv6
Operations
Subject: Re: I-D Action:draft-kawamura-ipv6-text-representation-01.txt

Hi Brian, All

Thanks for the comment!

yes. exactly.

Thanks,
Seiichi

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 23 Apr 2009 09:52:44 +1200

Hi Jeroen,

> what I have seen all platforms do lowercase hex fully compressed hex output.

Does "fully compressed" express :0: as ::? The draft recommends against that.

However, I agree that making the canonical format the same as is generated
by the existing API code seems like a Good Thing.

    Brian

---

From: Seiichi Kawamura <[email-masked]>
Date: Thu, 23 Apr 2009 12:51:22 +0900

Hi Jerry

Thanks!

> to choose only one of the compressible zero strings.

I agree. Bad choice of words on my part. This, we'll have to fix.

> instead of "Handling Leading Zeros" which might also mean "leading zeros

Good idea.

> length, the first string is replaced.".

I understand.
In 4.2.1, I was trying to explicitly say that
one should take the longest string of zeros and compress it fully.
There's one router I know that takes 2001:db8:1:1:1::
and shows it as 2001:db8:1:1:1::0
Let me think about this one.

Regards,
Seiichi

> length, the first string is replaced.".

- --
##########################################
NEC BIGLOBE Ltd.
   Platform Systems Division
   Seiichi Kawamura <[email-masked]>
   TEL   : 03-3798-6085 (FAX: 03-3798-6029)
   Mobile: 090-1547-4791
##########################################

---

From: Seiichi Kawamura <[email-masked]>
Date: Thu, 23 Apr 2009 13:16:23 +0900

Hi Brian, Jeroen

> Does "fully compressed" express :0: as ::? The draft recommends against that.

with inet_ntop

        if (best.base != -1 && best.len < 2)
                best.base = -1;

":0:" will return true for the if statement,
which means that it won't be compressed.

Most major operating systems (Unix, routers, etc)
will not compress a single 0 field, but there are
a few out there that will...

Regards,
Seiichi

---

From: Masanobu Kawashima <[email-masked]>
Date: Thu, 23 Apr 2009 16:27:49 +0900

Hi Brian, All

Thanks for the comment.

RFC4291 is described as "one or more groups".

Many operators would think that there are more than one 16 bit field.
Therefore , we recommend "two or more groups".

Fortunately, inet_ntop() is "two or more groups". :)

Regards,
Masanobu

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Hi Brian, Jeroen
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.6 (MingW32)
>
>iD8DBQFJ7+uXcrhTYfxyMkIRAiB3AJ0SNuHyHkj6F4gPMv4roC5rWKoN0wCffX0y
>WcYgWhATLtzY02hXcV7mtOY=
>=49zZ
>-----END PGP SIGNATURE-----

---

From: Adrian Kennard <[email-masked]>
Date: Thu, 23 Apr 2009 10:48:30 +0100

OK, sorry if this is out of place. I am working on router code (gigabit 
low power BGP IPv4/6 router hardware of our own design), and have some 
ideas for ways to simplify the set up of IPv6 tunnels using BGP in a 
couple of ways. One of which would solve a BGP/IPv6 tunnel issue we have 
encountered already.

Would this be best done via this mailing list or the GROW mailing list?

Any pointers on best way for me to discuss the ideas, confirm if there 
is an RFC or draft covering it (not found one yet) and draft an RFC is not?

Feel free to point me at a web site that tells me what to do.

Thanks for any help.

Adrian.

---

From: Mohacsi Janos <[email-masked]>
Date: Thu, 23 Apr 2009 12:37:10 +0200 (CEST)

Hi Adrian,
 	Are you referring 6PE (http://tools.ietf.org/html/rfc4798) or 
something new?

Best Regards,

Janos Mohacsi
Network Engineer, Research Associate, Head of Network Planning and Projects
NIIF/HUNGARNET, HUNGARY
Key 70EF9882: DEC2 C685 1ED4 C95A 145F  4300 6F64 7B00 70EF 9882

On Thu, 23 Apr 2009, Adrian Kennard wrote:

> OK, sorry if this is out of place. I am working on router code (gigabit low 
> power BGP IPv4/6 router hardware of our own design), and have some ideas for 
> ways to simplify the set up of IPv6 tunnels using BGP in a couple of ways. 
> One of which would solve a BGP/IPv6 tunnel issue we have encountered already.
>
> Any pointers on best way for me to discuss the ideas, confirm if there is an 
> RFC or draft covering it (not found one yet) and draft an RFC is not?
>

---

From: Adrian Kennard <[email-masked]>
Date: Thu, 23 Apr 2009 12:18:43 +0100

>     Are you referring 6PE (http://tools.ietf.org/html/rfc4798) or 

Not MPLS, no. Its IPv6 over IPv4 (protocol 41) tunnels and how to link 
IPv6 islands in a more seamless way using BGP.

If this is the right place to raise the issue I'll provide a few more 
details of the issues and solution if you like.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 23 Apr 2009 15:10:45 +0300 (EEST)

On Thu, 23 Apr 2009, Adrian Kennard wrote:
> Not MPLS, no. Its IPv6 over IPv4 (protocol 41) tunnels and how to link IPv6 
> islands in a more seamless way using BGP.
>
> If this is the right place to raise the issue I'll provide a few more details 
> of the issues and solution if you like.

Maybe you should take a look at the softwire WG.  They're dealing with 
similar problems.

But I fear there so far the idea hasn't gotten much traction. In fact, 
the RFC4798 predecessor documents [1] included ability to set up 
tunnels over GRE and similar non-MPLS encapsulations.  This was 
explicitly _removed_ because the solution was targeted at MPLS 
networks, not as a general purpose BGP-signalled tunneling mechanism.

[1] take a look at e.g:
http://tools.ietf.org/html/draft-ooms-v6ops-bgp-tunnel-00

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Ole Troan <[email-masked]>
Date: Thu, 23 Apr 2009 15:02:32 +0200

> But I fear there so far the idea hasn't gotten much traction. In fact, the
> RFC4798 predecessor documents [1] included ability to set up tunnels over
> GRE and similar non-MPLS encapsulations.  This was explicitly _removed_
> because the solution was targeted at MPLS networks, not as a general purpose
> BGP-signalled tunneling mechanism.
>
> [1] take a look at e.g:

I thought 6PE and BGP tunnelling got split into separate documents?
obviously my memory isn't serving me right.

you can still do BGP tunnelling with existing mechanisms. PEs are
connected through a full mesh of BGP peerings. each PE has an
automatic tunnelling interface (6to4, automatic tunnelling). BGP
next-hops are the 6to4/v4compatible address. note that 6to4 is only
used internally and the sites connecting to the PE uses native
addresses.

cheers,
Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 24 Apr 2009 11:33:36 +1200

Ole,

> obviously my memory isn't serving me right.

http://tools.ietf.org/id/draft-ietf-ngtrans-bgp-tunnel-04.txt
(thankyou Google)

I don't recall why that never became an RFC.

> used internally and the sites connecting to the PE uses native

Is there a full specification of this? Maybe the above draft
needs to be revived?

    Brian

---

From: Eric Levy-Abegnoli <[email-masked]>
Date: Fri, 24 Apr 2009 10:52:04 +0200

Brian,
> I don't recall why that never became an RFC.
That sort of became RFC4798, with focus on MPLS tunnelling
> Is there a full specification of this? Maybe the above draft
Any tunnelling of v6 over v4 would do, and each mechanism has its own 
spec. They just "work" regardless of the v6 content (for instance BGP 
v6). So I don't think we need to specify it further.
Eric

---

From: Adrian Kennard <[email-masked]>
Date: Fri, 24 Apr 2009 09:47:43 +0100

> used internally and the sites connecting to the PE uses native

OK, it is specifically the use of the next hop that I wanted to check. 
If that is covered by an existing RFC then great.

The idea is the use of a suitable IPv6 next hop for an IPv6 prefix 
announced via an IPv4 BGP session. Is the correct practice to use a 
2002:: prefix address as the IPv6 next hop to make the routing send via 
a protocol 41 IPv4 tunnel then? Is that documented?

There is another more radical idea I also have which maybe I'll raise as 
a separate issue though :-)

---

From: Adrian Kennard <[email-masked]>
Date: Fri, 24 Apr 2009 12:00:18 +0100

> I don't recall why that never became an RFC.

That is exactly what I am talking about.

It uses "The IPv4-mapped IPv6 address is defined in [V6ADDR]" as the
next hop. That means ::FFFF:x.x.x.x as an IPv4 address.

What is not clear to me is what this the best practice and workable IPv6
next hop to specify. Seems to me it could be:-

::x.x.x.x
::FFFF:x.x.x.x
2002:xxxx:xxxx::

The latter seems to express that we want to use simple protocol 41 IPv6
over IPv4 tunnelling. The first two seem to me to just indicate an IPv4
address as the next hop without saying how the traffic is to be sent to
it (e.g. GRE, protocol 41, whatever).

Do we need an RFC on this?

FYI, I'll make our routers understand any of the above as a next hop to
send over protocol 41 when received, but need to know what I should used
when generating this as a next hop to send.

---

From: Jeroen Massar <[email-masked]>
Date: Fri, 24 Apr 2009 14:09:54 +0200

Adrian Kennard wrote:
[..]
> next hop to specify. Seems to me it could be:-

That one was deprecated by RFC4291. I used to use ::/96 for storing IPv4
addresses inside IPv6, but then you don't know if :: is 0.0.0.0 or IPv6
::, as such I am now using the ::ffff::/96 in the places where I was
using that and the code that I have updated. Then ::ffff:0.0.0.0/96 is
for sure the IPv4 variant.

> it (e.g. GRE, protocol 41, whatever).

I would go for ::ffff:x.x.x.x, as then you have the properties you
describe above, but also know for sure that the 2002::/16 prefix can't
be hijacked by some routing entry, next to it being clear that this is
really on the wire as IPv4 and not as IPv6.

> when generating this as a next hop to send.

I do sincerely hope that you will be looking heavily at the security
concerns here, especially a line saying "only accept packets from known
prefixes" and "filter those prefixes out at the border" aka BCP38.

Greets,
 Jeroen

---

From: Ole Troan <[email-masked]>
Date: Fri, 24 Apr 2009 14:20:51 +0200

Adrian,

[...]

> when generating this as a next hop to send.

I believe you have to pick either ::x.x.x.x if you want to use IPv4
compatible automatic tunnelling or 2002:x.x.x.x:: for 6to4. the first
mechanism has been deprecated for a number of years, so I'd recommend
6to4. but it is basically an operational choice.

using a 6to4 address also implies how traffic is sent.

cheers,
Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 25 Apr 2009 08:42:28 +1200

> That sort of became RFC4798, with focus on MPLS tunnelling

Exactly; the non-MPLS methods were thrown away, although they
seem to be completely valid. Why isn't there an informational
or BCP RFC describing them? It really seems like a gap.

    Brian

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 25 Apr 2009 01:26:24 -0700

Hi Brian,

> or BCP RFC describing them? 

I am not sure if they were thrown away. RFC4798 cames from L3VPN 
paradigm and is sort of additional plug in for interconnect IPv6 islands 
over IPv4 core.

And since it is very much based on 2547/4364 any transport which applies 
to this would also apply to 4798. For example 
draft-ietf-l3vpn-gre-ip-2547-05 defines IP tunneling support.

Of course some vendors support automated multipoint GRE technic where 
your encapsulation header is automatically learned from BGP next hops 
allowing for very easy IP tunneling. For those vendors the very same 
functionality could be used for RFC4798.

 > It really seems like a gap.

I agree with you 100%. Unfortunately for some people dreaming about 
world of MPLS only core routers which are not able to route/switch even 
single IP packet this would be not a gap but a great feature :).

Cheers,
R.