8 messages, 5 authors, 2007-08-06 · open the first message on its own page
From: Doug Maxey <hidden>
Date: 2007-07-31 19:21:21
Howdy! I just got asked about ipv6 support in yaboot and a quick investigation showed _no_ knowledge of the address formats in the code. Should I be submitting an RFC for a full parser that can pick that apart? Or does has someone have code lurking in the shadows, that just needed some prompting? :) ++doug
From: Paul Nasrat <hidden>
Date: 2007-07-31 20:11:01
On Tue, 2007-07-31 at 14:21 -0500, Doug Maxey wrote:
Howdy! I just got asked about ipv6 support in yaboot and a quick investigation showed _no_ knowledge of the address formats in the code.
We really just use OF for obp-tftp and don't have our own ip stack, as there is no 1275 standard for ipv6 (although some modern IBM firmwares which also have iscsi support it) it's somewhat hard.
Should I be submitting an RFC for a full parser that can pick that apart? Or does has someone have code lurking in the shadows, that just needed some prompting? :)
Have you tried it with firmware that supports obp-tftp over ipv6? Paul
From: Doug Maxey <hidden>
Date: 2007-07-31 21:08:49
On Tue, 31 Jul 2007 21:11:01 BST, Paul Nasrat wrote:
On Tue, 2007-07-31 at 14:21 -0500, Doug Maxey wrote:quoted
Howdy! I just got asked about ipv6 support in yaboot and a quick investigation showed _no_ knowledge of the address formats in the code.We really just use OF for obp-tftp and don't have our own ip stack,
True. Was just curious about the handling of the address formats, where the xxxx:... will probably be used. Several spots already make lots of assumptions that the colons are only in the disklabel.
as there is no 1275 standard for ipv6 (although some modern IBM firmwares which also have iscsi support it) it's somewhat hard.
Oh, I agree completely. Publication is still being worked. The good news is that the description is already there. Once folks can see the whole enchilada.
quoted
Should I be submitting an RFC for a full parser that can pick that apart? Or does has someone have code lurking in the shadows, that just needed some prompting? :)Have you tried it with firmware that supports obp-tftp over ipv6?
Heh. Not yet, but RSN.
From: Paul Mackerras <hidden>
Date: 2007-08-01 01:03:12
Doug Maxey writes:
I just got asked about ipv6 support in yaboot and a quick investigation showed _no_ knowledge of the address formats in the code. Should I be submitting an RFC for a full parser that can pick that apart? Or does has someone have code lurking in the shadows, that just needed some prompting? :)
I would have thought that yaboot would just be passing any network addresses in text form to some OF method, so it's up to OF to understand ipv6 address formats. No? Paul.
From: Doug Maxey <hidden>
Date: 2007-08-01 02:37:56
On Wed, 01 Aug 2007 11:03:12 +1000, Paul Mackerras wrote:
Doug Maxey writes:quoted
I just got asked about ipv6 support in yaboot and a quick investigation showed _no_ knowledge of the address formats in the code. Should I be submitting an RFC for a full parser that can pick that apart? Or does has someone have code lurking in the shadows, that just needed some prompting? :)I would have thought that yaboot would just be passing any network addresses in text form to some OF method, so it's up to OF to understand ipv6 address formats. No?
Yes, yaboot _should_ just pass the text representation around. However, there are places that the context determination, for disklabels, is a simple check for the presence of ':'. When I did the original work for building in the tests for determining if the network device was really an iscsi block device, I may have been over-concerned that the non-disklabel parts of the IQN, which can and does have colons, could confuse the parsing. In the block device path, there was only a single questionable use. That usage was fixed by switching from strchr() to strrchr(). I expect the same syntax issues for the pure network side, as there is no chance to not take the network path for a pure ipv6 network boot. In my mind anyway. Which is always questionable. ;) ++doug
From: Segher Boessenkool <hidden>
Date: 2007-08-01 05:12:15
quoted
quoted
I just got asked about ipv6 support in yaboot and a quick investigation showed _no_ knowledge of the address formats in the code. Should I be submitting an RFC for a full parser that can pick that apart? Or does has someone have code lurking in the shadows, that just needed some prompting? :)I would have thought that yaboot would just be passing any network addresses in text form to some OF method, so it's up to OF to understand ipv6 address formats. No?Yes, yaboot _should_ just pass the text representation around. However, there are places that the context determination, for disklabels, is a simple check for the presence of ':'.
The network address is passed to OF as (part of) the device argument for the network device; and colons aren't legal characters in a device argument, so any OF implementation that would use colons in IPv6 addresses is terminally broken. This is completely analogous to the fact that filesystem paths cannot use forward slashes. (The third disallowed character is the at-sign, for completeness). Segher
From: Doug Maxey <hidden>
Date: 2007-08-01 21:01:06
On Wed, 01 Aug 2007 07:12:15 +0200, Segher Boessenkool wrote:
quoted
quoted
quoted
I just got asked about ipv6 support in yaboot and a quick investigation showed _no_ knowledge of the address formats in the code. Should I be submitting an RFC for a full parser that can pick that apart? Or does has someone have code lurking in the shadows, that just needed some prompting? :)I would have thought that yaboot would just be passing any network addresses in text form to some OF method, so it's up to OF to understand ipv6 address formats. No?Yes, yaboot _should_ just pass the text representation around. However, there are places that the context determination, for disklabels, is a simple check for the presence of ':'.The network address is passed to OF as (part of) the device argument for the network device; and colons aren't legal characters in a device argument,
yeah, pretty thoughtless of the IETF for not consulting the 1275WG. :)
so any OF implementation that would use colons in IPv6 addresses is terminally broken.
Ok. What is your proposed resolution that does not violate the rfcs? Namely RFCs 3986, 4038, and especially 4291.
This is completely analogous to the fact that filesystem paths cannot use forward slashes. (The third disallowed character is the at-sign, for completeness).
Not really. I don't expect to the the "device path" contain any ipv6 info. Just the parameters that follow on the end, e.g., not a real example, just an extrapolation from current usage using the existing addresses from a client and a server:
boot network1:ipv6,fe80::202:55ff:fed3:9e20/64,KERNEL-NAME,fe80::21a:64ff:fe44:1713/64,GWADDR,...
The above addrs after the first colon is the part that yaboot would have to deal with, if only to treat it as opaque token. There is no ppc64 OFW that supports this yet, but a version is expected soon. BTW, I don't really have any real input into how the OFW is designed, just try to adapt to what is implemented. ++doug
From: Segher Boessenkool <hidden>
Date: 2007-08-06 18:42:35
quoted
The network address is passed to OF as (part of) the device argument for the network device; and colons aren't legal characters in a device argument,yeah, pretty thoughtless of the IETF for not consulting the 1275WG. :)
Heh. That's not an issue; it just means that OF implementations need to use a (slightly) different spelling for IPV6 addresses. However, see below.
quoted
so any OF implementation that would use colons in IPv6 addresses is terminally broken.Ok. What is your proposed resolution that does not violate the rfcs? Namely RFCs 3986, 4038, and especially 4291.
Quotes from those RFCs would have been helpful.
quoted
This is completely analogous to the fact that filesystem paths cannot use forward slashes. (The third disallowed character is the at-sign, for completeness).Not really. I don't expect to the the "device path" contain any ipv6 info. Just the parameters that follow on the end,
There can be parameters at *any* path component though, not just the final component. It isn't too farfetched to imagine devices as child devices under a network device IMHO. Not the common case, sure.
There is no ppc64 OFW that supports this yet, but a version is expected soon.
There is an x86 OFW that supports it now. Some good news, too: The requirement for device arguments to not contain colons or at-signs has been deemed overly strict, since any defined use for those arguments should follow the path resolution algorithm that is spelled out in the specification itself; and that algorithm can deal with it just fine. Therefore, it now is an (unpublished :-) ) recommended practice for OF implementations to allow it. Forward slashes are right out, though :-)
BTW, I don't really have any real input into how the OFW is designed, just try to adapt to what is implemented.
Yeah I understand :-) Segher