|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
From: Joe Abley <jabley@hopcount.ca> In-Reply-To: <29A07C07-0B3B-4A1D-9AA3-A79413732E0C@steffann.nl> Date: Thu, 1 Nov 2012 10:51:49 -0400 To: Sander Steffann <sander@steffann.nl> Cc: nanog@nanog.org Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org On 2012-11-01, at 10:27, Sander Steffann <sander@steffann.nl> wrote: >> You really shouldn't need to parse these and it's perfectly valid to = reject them as invalid input. This really is an output only format [...] >=20 > I don't agree. I think it's actually the other way around. It's a = valid representation of an IPv6 address so you be able to parse them. = You don't need to be able to output them though. The active advice from the IETF on this topic would seem to be RFC 5952 = as updated by RFC 5952. RFC 5952 specifies (in section 5) that the least-significant 32 bits MAY = be written in dotted-quad notation if "it is known by some external = method that a given prefix is used to embed IPv4". People who make use = of a general-purpose v6 addressing plans which incorporate mapped v4 = addresses in the lower 32 bits fit clearly into this category, I would = think. 5952 is silent on the distinction between parsing such addresses = and using them in output. I don't see any justification in the standards for rejecting v4-mapped = addresses on input. For what that's worth. I agree that this adds a step to input validation, and that using = standard libraries for this stuff is a good idea. Joe
|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |