SP and mixed IPv6/IPv4 addresses
Aaron Howell
aaron.howell at deakin.edu.au
Tue Aug 12 20:30:06 EDT 2014
OT, I also don’t buy into the “IPv6 is doomed”. After a long lead time, IPv6 usage is looking on the rise according to Google: http://www.google.com/intl/en/ipv6/statistics.html and Akamai (historical): http://www.akamai.com/ipv6
Even if you don’t believe any of this - I would encourage everyone to have at least a vague plan for it happening - because despite what some people say, it is still one of the likely outcomes - and its better to spend a day or two to document a way to the destination that might be forced upon you - than being caught out later and be in dire straights with no paddle.
My home has IPv6, my ISP has IPv6, my personal VPSs have IPv6 (all currently dual-stack of course) - and I’ve convinced work to at least get IPv6 working for the main website in the strategic plan for the next 12 months. Our networking team has had an allocation for about 3 years but, like a lot of places, we have been twiddling our thumbs about it unsure of where to start with it.
I know our Regional Registry has hit its last /8 - and it’s draining slowly because of new restrictions on applications for IPv4 addresses in our area. I would not like to be the guy trying to get IPv4 addresses in a few years time - they will become a rare commodity, which as far as my supply and demand knowledge goes, means prices will go up drastically. If I had any faith that IPv4 was going to continue to be the norm - I'd buy some now and make a mint!
Cheers,
Aaron
On 12 Aug 2014, at 7:07 pm, Ian Young <ian at iay.org.uk> wrote:
>
> On 11 Aug 2014, at 21:24, Tom Poage <tfpoage at ucdavis.edu> wrote:
>
>> Institution uses both IPv6 and IPv4. Internal client (multiple
>> interfaces) authenticates against IdP via IPv6, but external
>> communication (to remote SP) is via IPv4. Triggers checkAddress error.
>> Not quite the proxy scenario in the error message.
>
> Not quite, but it's essentially the same scenario as the client-and-IdP-behind-NAT one that we started running into a few years back. The assumption that an entity's IP address is singular and the same for all observers has never been a good one.
>
> I recall this as being the reason that check address and check *consistent* address were broken out as separate checks in the SP. Of course with mobile devices the assumption that an entity's IP address is always the same for a given observer is also unsafe, although I don't think we've seen many problems stemming from that.
>
>> Certainly, checkAddress can be set false, but I also wonder whether
>> we'll start to see this kind of error more often as the world continues
>> to adopt IPv6.
>
> I'm not sure if I accept Scott's view that IPv6 is doomed, but note that IPv6 and NAT both introduce the same result, so whichever way it goes it looks to me as if checkAddress is going to be less and less something you want to enable at an SP.
>
> -- Ian
>
>
>
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
Important Notice: The contents of this email are intended solely for the named addressee and are confidential; any unauthorised use, reproduction or storage of the contents is expressly prohibited. If you have received this email in error, please delete it and any attachments immediately and advise the sender by return email or telephone.
Deakin University does not warrant that this email and any attachments are error or virus free.
More information about the users
mailing list