Subject: [v6ops] IPv6 prefix to use to store IPv4 prefixes in an IPv6 IP Address Managment System?

From: Mark Smith <[email-masked]>
Date: Tue, 17 May 2011 20:44:23 +0930

Hi,

It recently occurred to me that it could be useful to store IPv4 prefix
information in an IPv6 IP address management system, so that both IPv4
and IPv6 prefix information are kept in the same address
management database.

The only question I have about doing that is what IPv6 prefix to use
for these IPv4 prefix entries. The deprecated IPv4-Compatible IPv6
Address format would be convenient for this purpose as all bits
preceding the IPv4 prefix are zeros, making these entries very easy to
spot if you happen to be looking at the IPv6 form of them. Would that
be safe and reasonable to use the ::/96 prefix? Would it be worth me
writing up an ID proposing the recycing of this form of IPv6 address
for this purpose?

Thanks,
Mark.

---

From: Mohacsi Janos <[email-masked]>
Date: Tue, 17 May 2011 13:32:40 +0200 (CEST)

> writing up an ID proposing the recycing of this form of IPv6 address

I think it is only a representation, which can be specific for your 
application.  Parsing and implementing can be done  in the application as 
e.g.: ::192.168.0.1 or 192.168.0.1 or ::c0a8:1
Some application may decide to store IPv4 addresses in text, some in 
binary w.g in sockaddr_storage.

What is the motivation for standardise this?

Best Regards,
 	Janos Mohacsi

---

From: Philip Homburg <[email-masked]>
Date: Tue, 17 May 2011 13:49:37 +0200

>writing up an ID proposing the recycing of this form of IPv6 address

I would use IPv4-mapped. [::ffff:<IPv4 address>] is also easy to grep, it is
already in use in a lot of places and it avoids confusion for
[::] and [::1]. That may not be an issue in your application, but it
probably more convenient to have one format that is used everywhere.

---

From: Mark Smith <[email-masked]>
Date: Tue, 17 May 2011 21:36:44 +0930

Hi Janos,

On Tue, 17 May 2011 13:32:40 +0200 (CEST)

> What is the motivation for standardise this?

Similar to the motivation to have a specific documentation prefix. If
somebody wants to store an IPv4 address/prefix in an IPv6
variable/structure, there is a well known prefix defined for that
purpose. Certainly not necessary, but possibly quite useful.

The other alternative would be to use the IPv4-Mapped IPv6 Address
form. The description from RFC4291 seems to suit,

"A second type of IPv6 address that holds an embedded IPv4 address is
   defined.  This address type is used to represent the addresses of
   IPv4 nodes as IPv6 addresses."

although perhaps as this form is still in use for IPv6 applications to
receive IPv4 traffic, it might be better to have ::/96 as the
IPv4 address in IPv6 storage only well known prefix. ::/96 would be
easier and simpler for humans to deal with verses 0:0:0:0:0:ffff::/96
(as typing that in just demonstrated to me - I had to calculate the
number of ":0:"s and check them to make sure I had the right number).

Regards,
Mark.

---

From: Mark Smith <[email-masked]>
Date: Tue, 17 May 2011 21:49:25 +0930

Hi Philip,

On Tue, 17 May 2011 13:49:37 +0200
Philip Homburg <[email-masked]> wrote:

> [::] and [::1].

That is a very interesting point about [::1]. As an IPv6 addresses it
means something very different to the IPv4 value it would be when
interpreted using the IPv4-Compatible IPv6 Address format. Good thing
it is deprecated.

I think that suggests that ::ffff:<ipv4 address> is a better choice of
the existing IPv4 embedded in IPv6 address formats for this purpose.
That leaves the question of where there is any subtle traps with using
that IPv4 in IPv6 form for this storage purpose. 

>That may not be an issue in your application, but it

Thanks,
Mark.

---

From: Joel Jaeggli <[email-masked]>
Date: Tue, 17 May 2011 14:40:03 -0700

I would think that the appropriate  method would be to have an ipam system which supports both ipv4 and ipv6 addresses within it's data structures... if you store the v4 addresses in the v6 representation your engineers will eat a bullet every time the have to convert hex to decimal.

current versions of racktables or the U of O's netdot are capable of handling this.

On May 17, 2011, at 4:14 AM, Mark Smith wrote:

> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Mark Smith <[email-masked]>
Date: Wed, 18 May 2011 07:24:07 +0930

Hi Joel,

On Tue, 17 May 2011 14:40:03 -0700

> I would think that the appropriate  method would be to have an ipam system which supports both ipv4 and ipv6 addresses within it's data structures... if you store the v4 addresses in the v6 represe…

That's the thing. If there is a well known IPv6 prefix for this, then
the routines that displays addresses or accepts them as input can
easily recognise IPv4 prefixes embedded in IPv6 prefixes and
convert them backwards and forwards for storage in the IPv6 fields. The
rest of the IPAM internals are IPv6 only.

I'm not strongly disagreeing with handling IPv4 and IPv6 separately in
an IPAM. It's just that it occurred to me that handling IPv4 as a
special case subset of IPv6, with the few differences being limited to
displaying, input conversion, and prefix length handling, that it might
be a bit less development effort than handling the protocols as
separate and unrelated cases throughout the IPAM.

Thanks,
Mark.