ipv6 in yaboot

ipv6 in yaboot

[Doug Maxey]

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

Re: ipv6 in yaboot

[Paul Nasrat]

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

Re: ipv6 in yaboot

[Doug Maxey]

On Tue, 31 Jul 2007 21:11:01 BST, Paul Nasrat wrote:
>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, 

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.

>
>> 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.

Re: ipv6 in yaboot

[Paul Mackerras]

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.

Re: ipv6 in yaboot

[Doug Maxey]

On Wed, 01 Aug 2007 11:03:12 +1000, Paul Mackerras wrote:
> 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?

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

Re: ipv6 in yaboot

[Segher Boessenkool]

>>> 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

Re: ipv6 in yaboot

[Doug Maxey]

On Wed, 01 Aug 2007 07:12:15 +0200, Segher Boessenkool wrote:
>>>> 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

Re: ipv6 in yaboot

[Segher Boessenkool]

>> 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.

>> 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.

>> 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